# Converting Modifiers to Nodes

**Conclusions**
* The behavior of existing modifiers will not change.
* Every modifier will still be available in the "Add Modifier" menu, even if it is internally implemented with nodes.
* Some modifiers are useful to have as nodes and can be implemented directly, sometimes with more than one node.
* Instances are made real before evaluating "legacy" modifiers, and point clouds are converted to vertices.

**Questions**
* For modifiers converted to node groups, expose the node group like the "Nodes" modifier?
* Until we can have the same customizable UI for Node Group properties exposed in the modifier, **no**.
* We can still have a "convert to nodes" operator for those modifiers to expose their internal node group.

**Plan of Action**
* Coordinate with the module members (community) to convert most modifiers to nodes.
* Create mockup for 5 nodes, and add more once those are implemented by the community.

**Functionality Available**
| Name | Note |
| ---- | ---- |
| Vertex Weight Proximity | Attribute proximity node |
| Volume to Mesh | In the volume to mesh node|
| Vertex Weight Mix | What a nice improvement we have here.|
| Edge Split | |
| Wave | Should be possible to build already with a large node group. |
| Triangulate | |

**Functionality Mostly Available**
| Name | Note |
| ---- | ---- |
| Vertex Weight Edit | This allows changing a vertex group with a curve mapping widget, low priority for now. |
| Boolean | Just needs the "Self" option, and to work with instances. |
| Particle Instance | The "Create Along Paths" option is not possible yet, but I imagine that use case will be handled differently in geometry nodes. |

**Needs Completed Functionality**
| Name | Note |
| ---- | ---- |
| Subdivision Surface | Needs the extra options added more recently, needs a separate "Simple Subdivision" node. |
| Displace | Needs the `normal` attribute. |

**Ready to Implement**
There are no open design questions, but there may be code architecture questions to answer before work starts. For example, modifiers generally retrieve weights from vertex groups, but geometry nodes do not create vertex groups. Two problems with this:
- Vertex group names are stored at the object level, which will not work at all here.
- Likely solutions probably involve bad hacks, which we should really not be adding.

My maybe controversial opinion: Whenever a problem like this comes up-- don't share code, just rewrite or duplicate it. Most of these modifiers are not too complicated anyway.

| Name | Note |
| ---- | ---- |
| Mesh to Volume | |
| Weld | Theoretically simple, reusing code may be the challenge. See [some more thoughts](https://hackmd.io/@HansGoudey/BJHnKF1WO). |
| Data Transfer | We already have the idea of an "Attribute Transfer" node. |
| Remesh | Important to set up a base for more remeshing methods in the future. |
| Curve | Mockup below. Requires curve support in geometry nodes, which I would like to explore design for. |
| Bevel | Procedual modeling classic. A nice use case for attribute inputs, custom profile should use proper curve geometry. Mockup below. |
| Build | Should be replaced by "Delete Faces" node, and probably an `index` attribute. |
| Mask | Can also be replaced by "Delete Vertices". Though, the armature mode would need design work. |
| Shrinkwrap | Can be generalized with "Attribute Transfer Node" / "Attribute Proximity". |
| Mirror | This should be relatively simple to implement. |
| Weighted Normal | I don't know enough about the use case. Exposing `normal` attribute is a first step. |
| Cast | Can be generalized with "Attribute Transfer Node" / "Attribute Proximity" and primitive nodes. |
| Decimate | Unforunately requires BMesh conversion, but looks simple to convert. |
| Screw | Simple version would be quick, but the "Stretch UVs" option should really be generalized. |
| Solidify | Mockup below. |
| Wireframe | Uses BMesh, which, like Bevel, raises the question of how to pass information. |
| Smooth | Quite simple, should just be rewritten in C++. |
| Laplacian Smooth | Looks relatively simple. |
| Warp | Should be relatively simple, but what is the use case? |
| Volume Displace | Should be relatively simple, but should be discussed briefly to make sure it fits into geometry nodes design. |
| UV Project | Should be relatively simple to convert this, but may need to be changed for attribute access. |
| Armature | Might be a very large project, many object level operations. |

**Needs Design**
| Name | Note |
| ---- | ---- |
| UV Warp | Can probably be accomplished with attribute system. Investigation needed.|
| Mesh Sequence Cache | Would be very powerful to reference external geometry in a node tree. Maybe this should be generalized though. |
| Lattice | Design unclear. Does lattice data become a geometry component type? |
| Array | Idea of instancing a geometry in multiple places needs more design work. |
| Laplacian Deform | Requires binding (persistent storage over evaluations). |
| Mesh Deform | Also requires binding. |
| Mesh Cache | I have a feeling this is deprecated in favor of the Mesh Sequence Cache modifier? |
| Simple Deform | Probably fine, but maybe this could be generalized somehow? |
| Hook | Needs bind operations in edit mode (persistent storage). |
| Normal Edit | Exposing normal attribute(s) may be enough for this. |
| Surface Deform | Requires binding. |
| Smooth Corrective | Requires binding. |
| Skin | Requires binding, marking root, etc. |

**Simulation**
| Name | Note |
| ---- | ---- |
| Soft Body | |
| Explode | Requires current particle system. |
| Fluid | Canonical example for the generalized solver idea. |
| Ocean | This works differently from the other simulations, since it is self contained. |
| Cloth | |
| Collision | This is just a static "collider" tag, and a storage for settings. |

**Not to be Replaced**
| Name | Note |
| ---- | ---- |
| Multiresolution | Needs design / architecture work. Object data type? Does not fit into geometry nodes design. |
| Particle System | To be replaced by particle nodes. |
| Dynamic Paint | This idea should be more generalized. |

## Mockups
### Bevel
- Input weights and vertex group is replaced by a single attribute on either vertex or edge domain. The expected type would be float or boolean, with the latter mapping nicely to the idea of selections.
- The custom profile is moved to a separate node that creates a curve geometry based on the widget data, the bevel code accepts a curve for the profile.


### Curve
- Renamed to "Curve Deform" to separate it from the curve geometry type also present in geometry nodes.
- The modifier itself looks quite simple, the larger task is basic support of curve data in the geometry node tree.


### Solidify
- Only complex mode is provided in the UI, since it's the newer, more effective implementation.
- The node can output two result boolean attributes.
- "Only Rim" becomes an "Invert Selection" and "Delete Faces" node after the operation.
- Setting data on the output geometry moves to separate nodes, where we can add the idea of limiting the operation to a certain selection. This cannot be implicit, since there can be multiple selections output from one node.
- "Shell" as a name is not clear, maybe it could be renamed.

_Image missing "Merge Threshold"_