Blog 8 - Not Nodes, Modifiers.
I'm so excited to share a new discovery (sort of) with you all! I've been working really hard in Blender for a while now to create something that may sound silly, but the underlying system has enormous potential.
The inspiration
For the longest time I haven't liked how I show nodes and node networks in my videos. I want something more visually interesting and unique that I can animate easily to help discuss all of the nodes. So, I've been building Nodes in Geometry Nodes.
Old Node Visual
Quite literally I've built a system to make a 3D representation of nodes, but that's not the exciting part. What is exciting, is that it uses multiple node networks working in tandem to create a highly dynamic and flexible system that's easier to use and more customizable than a single node network can be alone.
Honestly, I believe this is the best way to think about Geometry Nodes and may even be the intended way to use them (for complicated projects). Obviously I don't know that for a fact, but I do know that it enables us to do more than we could before! The general idea is to think of Geometry Node graphs as modifiers, because they are! I know that sounds self evident, but it took me a long time to fully internalize this and realize the full implications. In fact, this directly builds off of what I was saying last week.
Building from Last Week
All of the Objects here have the same Modifier and Individual Inputs for Animation
In my previous blog post I spoke about not using a singular node setup to make the final result. I took this a step further this week while making a quick animation for my website. I was about to make a huge network that would've taken forever to build and, subsequently, animate. Then I realized I was falling into the same trap I always do, so I stopped myself and made a smaller setup that's intended to be a modifier. Then I took that object with the modifier and copied it so that I could focus on animating the parameters on all of my objects instead of making all of the objects in the node network. This saved me a ton of time by allowing me to model and animate by hand. But we can take this a step further.
Going Even Further!
Next I realized not only does Blender work better when you use Geo Nodes as modifiers, but Blender was built to have a stack of modifiers; so why not have a stack of modular Geometry Nodes?
Manually Duplicating and joining Custom Node Groups
Specifically this solved a pretty large problem I was having with my 3D Nodes: I can't have dynamic inputs that I can change on a whim to make different 3D Nodes. In geometry Nodes we have no way of adding inputs if we want to duplicate portions of the node network, we can only copy and past custom node groups and restructure the graph around the new nodes. But that's not good enough. I want more flexibility.
One solution I thought about is to use Python to create dynamic nodes graphs that can change with a custom plugin-in UI, but implementing this is easier said than done.
Example of an Object Made by Stacking Geo Node Modifiers
So why not duplicate the modifier that would otherwise be the copied node group? Surprisingly, this does everything that I need it to! This gives us an easy way to duplicate the inputs we need. And by making different node networks for each piece of geometry we can make a fluid and dynamic system! From here we need to pass data from one modifier to the next, so we just have an output on our node network and use that output as a driver for the subsequent modifier, right. Right?
Some Limitations...
Unfortunately, that's not the case, because we can't just use outputs as drivers. Apparently those outputs are only evaluated once the modifier is applied, or if it exists as a node group inside of another Geometry Nodes graph. So is there any way to get around this?
... And Solutions
Yes, actually! Back when I was researching for-loops and function nodes (before we got simulation nodes and repeat nodes) I was playing around with the idea of storing data on points and reading that data recursively down the line. This is one way that Entagma solved the Plexus Effect that I mentioned in my own Plexus Video, and how we can move data down our modifier stack.
Adding a Point to Store Data for the next Modifier to Use
What we need is some geometry that will save our data as an attribute so we can read that attribute in a later modifier. I did this in two ways, with the geometry I'm creating anyway, and with a point in a point cloud. I won't get into all of the details about how I did this here (this is definitely going to be a whole video), but both methods successfully manage to pass data down the stack. Now we can duplicate and modify our modifiers to our heart's content!
There's a lot that I've glazed over here, but that's the gist of the system I've built. Now, for what most people do with Geometry Nodes this is highly unnecessary, but for those working on larger projects this can bring what once seemed unthinkable well within reach. I'm working on a video that will outline both my project and the general mindset of making modifiers instead of custom nodes, so be on the look out for that!
Other wise, that's all for this week. I hope this was helpful, and I'll see you in the next one!
Imported from Patreon. Original Post date: Apr 5, 2024
