Sub-Object Selection in Edit Modifiers
 
 
 

The sub-object selection levels for edit modifiers reflect the sub-object types for the object type that the edit modifier is designed to edit. For example, the Edit Mesh modifier supports three sub-object selection levels: vertex, face and edge. These correspond to actual elements of a TriObject. In contrast, the sub-object levels of the Bend modifier, are gizmo and center. These have no correspondence with the object that the bend modifier is modifying.

Edit modifiers typically allow the user to select sub-object elements of the object and perform at least the standard move/rotate/scale transformations. They may also support other operations such as the Edit Mesh modifier's extrude operation.

Edit modifiers have to store the selection. If the input to an edit modifier changes, the modifier will need to reapply its modifications. If a user modifies points after an edit modifier is applied, then the changes it made to the points will not be applied to the original object. For example, the Edit Mesh modifier stores changes made to the vertices of a mesh by maintaining an array of 3D vectors that represent a delta for each vertex. This delta is applied to an object by simply adding each delta to its corresponding vertex.

If the topology of an object changes, a vertex's index might change. If this is the case the user is given a warning message that a modifier exists in the stack that depends on topology (see the method Modifier::DependOnTopology() for the details on how an edit modifier informs the system it is dependent on topology). If the user selects OK from the warning message dialog the topology may be changed. The least that an edit modifier should do is not reference a vertex out of the range of an object's vertex array. The Edit Mesh modifier continually scales the length of its delta array to match the length of the vertex array of the incoming object. This ensures that the deltas are all applied to legitimate vertices, but if the topology changes, the effect is rarely usable.

The changes on an object are typically stored in the ModContext::localData public field which is a pointer to a LocalModData derived class. When an object is copied, the modifier context (and therefore the LocalModData) is also copied making it possible to copy objects with edit modifiers applied to them.