Dev:2.8/Source/Modifiers

Modifier stack port

This document describes project related on porting modifier stack from DerivedMesh to Mesh.

Reasoning

Blender 2.8 design states, that all the final evaluated data which is to be rendered is stored in Mesh format. This simplifies a lot integration with Draw Manager, overlay engine, render and engines. Project breakdown Modifier stack itself

Note This section is about mesh_calc_modifiers() function from DerivedMesh

The outer loop of modifier stack (the one which iterates over modifiers and applies them) is to be ported first. General logic of it will stay roughly the same. The only difference would be that it will be using Mesh instead of DerivedMesh for the result and intermediate calculation.

It is important to have code layed down here first, so we can instantly see the results of ported modifiers. Modifiers themselves can stay disabled / ignored from this loop for until they are properly converted.

Note When/if needed, we can have temporary DerivedMesh-to-mesh and vice-versa conversion to compare modifier result before/after. Or maybe to support modifiers before they are natively converted

Utilities

Modifiers module has utilities functions, which deals with vertex groups, texture, and DerivedMesh conversion.

Those functions are likely to be looked at first, before doing actual conversion of the modifiers -- some of those functions will be first function call in lots of modifiers anyway.

Note, that CDDM (Custom-Data Derived Mesh) is very close to Mesh, which is also storing data inside of CustomData arrays.

One of the parts which is not in the Mesh is BVH tree. That part would need to be ported to Mesh as well (should be more or less matter of adding BVH cache storage to a “runtime” part of mesh. It should already be possible to construct BVH from Mesh).

Deformation-only modifiers

Those are probably most easy to be converted. They receive DerivedMesh, so they can access vertex groups, and some modifiers will also need to access topology. Output of those modifiers is an array of deformed vertices.

Deformation is accumulated for all subsequent deformation-only modifiers, and then applied on a DerivedMesh at the end of the stack or before applying non-deformation modifier.

Since no geometry is being generated here, porting those modifiers will main consist of making it so topology and vertex groups is read from the Mesh which is passed to the modifier.

Constructive modifiers

Those are creating new geometry. There are some exceptions, but mainly they are working with CDDM.

First thing would be to introduce function which will replace DM_from_template(). Then, it should all be matter of making it so topology is read Mesh structure. The rest of the modifiers code should be relatively straightforward, since that code is mainly filling in given CustomData arrays.

Subsurf and Multires

We don’t currently have final design here, so for now best plan seems to be to convert Mesh to DerivedMesh in the beginning of subsurf/multires modifiers, do all the subsurf code in DerivedMesh, and convert DerivedMesh to Mesh at the end of those modifiers.

Sculpt support might need some special exceptions to get access to the multirees DerivedMesh. Probably easier for now to store those as a runtime data in Mesh.

Note Final subsurf / multires integration should be aligned with the plan of going OpenSubdiv for CPU side evaluation as well

Taskforce

The plan should be to get core parts done first, and have handful of modifiers of different type converted. That way we can have more people from the community to help us doing conversion. Just similar to OpenGL taskforce.