From BlenderWiki

Name

Joseph Eagar

Blender's mesh system has been in need of a refactor for years. As part of this project, I propose to rewrite the modifier system to implement a new DerivedMesh system. This new DerivedMesh system will solve many of the design issues the current DerivedMesh (and in fact the mesh system in general) suffers from. As an immediate benefit to users, the modifier system will become node-based.

Motivations

The modifier stack currently provides very little mesh support for modifiers, most of which are expected to implement their own set of mesh utility functions. Non-deformation modifiers must also have separate versions for editmode and object mode, or else use an expensive conversion option. Most of these issues are a result of the current state of blender's mesh system in general, and can be solved by creating a new DerivedMesh interface.

Blender's mesh system suffers from a variety of issues. The system has no adjacency support, and only supports quads/triangles. Triangle support is done via a hack that often causes issues with per-face-vertex data such as UVs. The memory management is done differently when editing a mesh in edit mode, which has resulted in a lot of awkwardness in the modifier system.

Since rewriting all of blender's mesh system would be outside the scope of a SoC project, the refactoring will be limited to reimplementing the modifier system. Modifiers will become node-based, and have access to many more mesh utility functions (such as remove doubles (split into two functions, find doubles and weld verts), extrude, etc, all part of the new DerivedMesh interface.

Theory

Rewrite the Modifier Stack

Ultimately the purpose of this project is to advance the mesh refactor while providing immediate benefits to users. To this end, the project will be limited to rewriting the modifier stack. In many ways, the modifier stack will become far more advanced then the rest of the mesh code.

Node-Based Modifiers

Since the modifier system must be redone anyway, the modifier stack will become node-based (this should only be a little more difficult then simply implementing a new stack-based API). The existing bNode system will be reused for this purpose.

A new DerivedMesh

A new DerivedMesh implementation is planned. Several key points of its design has already been worked out. Specifically:

• This new interface will not make assumptions about how data is stored in the back-end:
  • The new DerivedMesh interface will not be limited in the number of verts per faces. So backends will be allowed to support ngons.
  • Some operations will not even assume the backend is a mesh, allowing for e.g. better integration of curves and surfaces into the modifier stack.
• This new DerivedMesh must require mesh kernels to implement a set of simple operations, though not as many as typical boundary representations.
• Users of DerivedMesh must be able to query exactly which operations are supported. This is important, as some DerivedMesh code may even be reusable on non-mesh objects (such as an array modifier on a curve).
• On a high-level, mesh kernels must implement a specific interface to access mesh data, via special iterators that also act as containers for data. This will be in addition to whatever other APIs the mesh kernel may have.
• Reference to mesh elements (e.g. verts, edges, faces, face-vertices) will be done using a generic intptr_t that the back-ends can use to store either an index (preferred) or a pointer if they must.
• There will be a system to convert between backends. For example, a loop subsurf modifier might require a triangle-optimized backend. And some modifiers and tools will require a BMesh backend.

Deliverables

The main purpose of this project is to rewrite DerivedMesh. As this is a large project, it will be done in an incremental way. As this may be quite time consuming, the main goal is to complete a basic implementation and refactor the modifier system to use it.

Specifically, the following schedule is proposed:

• (Week 1) Collect design requirements and design the new DerivedMesh system.
• (Weeks 2-3) Write out a basic implementation of the new system, wrapping BMesh, EditMesh and Mesh.
• (Week 4) Write support for customdata in this system.
• (Weeks 5-6) Write a new infrastructure for the modifier system, and implement the subsurf modifier.
• (Week 7) Review the code written thus far, and work out any design issues. A maximum of 4 days would be allocated for this.
• (Week 7.4+) Rework the other modifiers to make use of this new system. The rest of the period would be alotted for this.

Long- and Short-Term Benefits

The short term benefits would be an increase in the speed of the modifier system, as modifier mesh data would be cached much more efficiently then is currently done. Modifiers would all support ngons, allowing (for example) the possibility of finally making use of our subsurf code's internal ngon support. Interfacing this system with the current fgon implementation will not be difficult.

Node-based modifiers will allow users to create more flexible modifier setups. Users will be able to animate modifiers via the existing time node. All remaining restrictions as to the order of modifiers will be removed.

The long-term benefits will greatly affect every aspect of blender's mesh code. Currently, DerivedMesh is one of the biggest obstacles to completing the planned mesh refactor. The new core mesh code (BMesh) has already been worked out, yet integrating it with the current DerivedMesh system has proven to be a great obstacle. Some form of refactoring is needed to allow future progress of the code. This project will do just that within the scope of the modifier system.

Bio

I'm a 21 year old student at Northern Arizona University. I previously have done a lot of work on blender's mesh system, including a half-edge implementation (not used) and helping with Geoffry Bantle's BMesh project. I initially adapted the current DerivedMesh for BMesh, though later it was decided to abandon the current DerivedMesh design in favor of a new system.