As the title says, we all want to see things like modifiers and particles become node-based in 2.8. However, we are faced with the reality of FOSS, that being limited resources and the limited ability to hold onto experienced people.
Therefore, we may need to do it as a serious of smaller steps if we want to see good results make their way into master (and as such having full-blown generic nodes in one go may just be too much). How do we do it then?
First step; code a series of specific, standalone node-tree types for things like modifiers, constraints, and particles;
Essentially, these would have some similarities to the Cycles node system in that there would be a special input/output for the main data type. The standalone nature of each of them would mean they can be coded and committed one at a time and as such be more achievable and manageable, an example for modifiers below where we start with just a straight translation of the stack to nodes, such as…
<i>Input > <b>array</b> > <b>subsurf</b> > <b>simple deform</b> > output</i>
However, we could also have merge nodes that combine multiple branches back together (so the derived mesh output is added on top of each other, this could mean things like…)
<i>Input > <b>solidify</b> (inset by 0.1) > combine > output</i> <i>> <b>solidify</b> (inset by 0.2) ></i>
The result would be a mesh that has two inner layers spaced according to the original’s normal data
But then, some nodes that can take objects as an input could now make use of derived mesh results from a node branch if desired, such as…
<i>Input > <b>subsurf</b> > <b>boolean</b>(difference) > output</i> <i>> <b>simple deform</b></i> -- o(boolean object)
And then you have the usual power from things such as texture inputs (the example below would create an array of objects with random offsets
<i>input > <b>array</b> > output</i> <i>texture > math(*2)</i> -- o( OffsetX ) -- o( OffsetY ) o(OffsetZ=1)
We could forget about very low level operations for the moment (such as ones for matrix math), even basic modifier nodes such as the above would already be enough to really increase Blender’s non-destructive power.
Step 2, develop node types that would allow trees to communicate with each other
Naturally, each new node tree type would be a datablock type as well, so one would have special input nodes that allow the results of one tree to be fed into another, an example being the result of a texture node tree being fed into a modifier node input.
Step 3, eventually tie everything together with low-level nodes and eventually merge the tree types
This would cover things that were worked on in the object nodes branch, such as matrix math nodes and the like, this means that sometime in the far off future, the BF will finally have the means to pull everything together and allow for unlimited power in modeling and animation in a glorious node soup.
What would your approaches be?