Dev:Source/Modifiers

{{#dpl:

 |debug=0
 |skipthispage=no
 |mode=ordered
 |namespace=
 |titlematch=Dev:Source/Modifiers/%
 |shownamespace=false
 |format=Subpages,²{#ifeq:²{IsUpper¦²{SUBPAGENAME:%PAGE%}²}²¦1¦²{Multiply¦*¦²{#expr:1+²{PagetitlePartsAmount¦%TITLE%}²-²{PagetitlePartsAmount¦²{PAGENAME}² }² -1 }² }² ²{SUBPAGENAME:%TITLE%}²¦}²,,

}}

---

Modifiers

I am working on a long overdue rewrite of the way mesh modifiers/effects are handled in Blender.

Current Features

Currently Blender supports the following deformations/effects on a mesh:

• Deforms - move the vertices of the mesh according to some relation
  • Armature
  • Curve
  • Hook
  • Lattice
  • Vertex Key
  • Wave
• Effects - perform some more complicated operation that can change mesh topology
  • Subdivision Surfaces
  • Build Effect
  • Effects additionally break down into two categories:
    • Constructive: Modifier only adds to mesh. This is important because it means that the original mesh vertices/edges/faces still "exist" in the modifier mesh and so it is reasonable to, for example, find out where a certain "original" vertex has been moved to for the purposes of vertex parenting.
    • Nonconstructive: Modifier can do anything to mesh and other parts of Blender cannot make any assumptions or queries about relationships between the original mesh and the modified one.

Additionally particle systems are currently implemented as a mesh effect, although technically they don't really fit very well into this category.

Problems with current implementation

Essentially the available features are not integrated consistently or in an organized fashion, making the system hard to understand and modify. Although simple modifiers could be added easily, adding complicated effect style modifiers is an annoying task.

Goals a new modifier system

The following are the primary design goals for a new system:

• User control
  • The user should have explicit control of when and how modifiers are applied, for example enabling certain modifiers for only render time, or enabling/disabling them during edit mode. The user should also be able to attach modifiers to a mesh datablock or an object datablock (or both).
• Extensibility
  • It should be easy to add new modifiers of either the simple deform only type or the more complicated effect type. New modifiers should exist as 100% equals with the current modifier (i.e. support same rich level of display/editing as others). It should be possible to quickly prototype modifiers of both types in Python.
• Generality
  • Modifier objects in general should support the same level of editing/interactivity as regular meshes. Meaning drawing types should still be respected and extra features like fastshade mode should work as expected.

Requirements for the modifier system

Side note: The intent is that the modifier system will eventually encompass all "data"-type objects in blender (i.e. objects other than Camera, Lamp, Empty, etc.), however the initial focus is on meshes so that is what will be discussed.

The basic idea behind modifiers is fairly simple: instead of using the actual mesh data, you just run several modifier functions that take the old mesh, convert it to a new mesh, and you do simple do this in a chain until you have processed all the modifiers. The mesh that you end up with you treat like it was the actual mesh. There are two reasons that the system must be more complicated than this.

The first is efficiency, for simple deformers you don't want to actually copy the entire mesh, just supply new vertex positions. Even more drastic, for a very complicated effect like subdivision surfaces you don't even want to generate a new mesh at all - the subdivision surface modifier can store the subdivided output much more effectiently by not creating a proper Mesh structure (with all the vertices, etc.). If the modifier is to be able to do this, then that means the modifier must supply methods the other parts of Blender can call in order to work with the mesh (the most important methods are the ones to just draw the modified mesh to the screen).

The second reason is that when editing the mesh there are often several levels that the user might want to work out. For example, in edit mode, the user will naturally be making changes to the actual mesh data, but they might want to have the deformed (or subdivided) mesh displayed during editing. Because the user might not necessarily want the "final" mesh in the modifier chain to be displayed, there need to be several ways to get a modifier mesh. A slightly related concern is that some other parts of blender may depend on the vertex locations of the mesh (dupliverts or vertex parenting) and so it must be possible to get the deformed location of these vertices (but before a constructive/destructive effect like Build or Subdivision Surfaces is applied).

The requirements break down as follows:

• Modifier entry points
  • It must be possible to retrieve:
    • Editmode: The mesh after only modifiers that should be active in editmode have been applied (for example, only Subdivision Surfaces).
    • Non-deformed: The mesh after all no-deform modifiers have been applied. This is needed to retrieve orco (original coordinate) data for modifier meshes.
    • Only deformed: The mesh after all initial (top-of-stack) "deform" style modifiers have been applied but before any others have been.
    • Final: The mesh after all modifiers have been applied.
    • Final-render: The mesh after all modifiers have been applied, but for modifiers which support different settings for interactive/render the render settings should be used.
• Modifier methods (a modified object must support these queries)
  • Convert to mesh: A modifier object must be able to be converted to a mesh (for: export, convert to a mesh, render).
  • Vertex mapping: It should be possible to ask a constructive or deforming modifier where a certain vertex has moved to (for: optimal mode selection, vertex parent)
  • Drawing: A large number of methods are necessary to allow the blender drawing system to draw a modifier without making assumptions about its data.
  • Selection: For modifiers that can be active during editmode it is necessary to either have the modifier draw its own selection data or provide enough info back for the system to be able to do so.

Implementation

there is DerivedMesh

http://mediawiki.blender.org/index.php/Release_Notes/Python#Mesh exposes it to python via mesh.getFromObject()

I am working on documenting the current modifier stack implementation here.

--Artificer 13:34, 4 June 2006 (CEST)

Further Work

As currently being implemented the main limitation of the system is that it won't be able to completely override the editmode level editing of the mesh. For example, I will probably write an auto-mirror modifier which should work just fine, but you won't be able to select both sides of the auto-mirrored (derived) surface in editmode, because the editmode system will only see the actual vertices in the mesh (it is possible to map the mirrored vertices back to their counterparts, but then transform won't go in the right direction (it won't be mirrored)).

It is probably worth fixing this in a general way at some point, however, because that will open up some very cool possibilities. One particularly compelling one is being a "tweak" modifier that would allow you to edit the vertices of the tweak modifier input. This means you could apply a subsurf and then edit the subdivided vertices. In theory you could then even apply another subsurf level, which would essentially mean you could do multi-level subdivision surface editing (although performance might not be that optimal). Another interesting possibility is being able to vertex key a subdivided mesh.

-- DanielDunbar - 16 Jul 2005

Removing the "Original Data" Restriction

I am currently experimenting with a patch to remove the "Original Data" restriction on the modifier stack (i.e., modifiers such as Curve can't be applied after non-deforming modifiers, as they require access to the object's original data). The idea is to have a flag in the ModifierData structure which indicates whether original data is available. Individual modifiers can then enable/disable functionality based on that flag (e.g. Curve can disable Vertex Group functionality if original data is unavailable). I hope to further extend this to remove the "Original Data" restriction altogether.

-- Artificer 04:24, 3 February 2006 (CET)

Object Modifiers

Recent discussion has yeilded some new concepts as to how modifiers can be extended for use elsewhere in Blender. It was apparent that functions like DupliFrames and DupliVerts were very similar to the Array Modifier with the exception that the aforementioned features create non-editable instances of the object being duplicated. Some users found this functionality to be more desirable than the "single mesh" approach that the Array Modifier uses. The next logical step, it was decided, should be an "object modifier stack" very similar to the existing mesh modifier stack. This new set of object modifiers could potentially include:

• DupliFrames
• DupliVerts
• Array
• Mirror
• "Onion Skin"/Ghosting

Further discussion on this proposed feature can be found here.

Desoto 00:40, 14 August 2006 (CEST)