Blender 3.6 LTS will come with Simulation Nodes. Daily builds of 4.0 alpha or 3.6 LTS beta both have this feature by default. So far there are also two demo files available to help testing:
I would like to invite anyone who tried this feature to give some feedback regarding the existing toolset, what you managed to acchieve so far, any showstoppers you may have found, and which workarounds you used.
I’m also curious to know if anyone has used the Delta Time option. It is intended to make simulations working consistently regardless of the scene FPS, and to be future-proof with the upcoming Realtime mode.
I may not be able to reply to everyone, but I (and the team) will read all the comments.
I’ve only put together 1 larger sim on my own so I’ve only run into the “typical” issues currently.
The sim is particle based where each particle is either repelled or attracted to every other particle. So it required Entagma’s n^2 loop workaround. I had to manually create n^2 points and use that to create all combinations of pairs of indices so I could accumulate all the Forces between them. Seems like “Serial loops” will not help for this case still.
I do use Delta Time in the sim for exactly the reason to be agnostic to scene FPS. However, in practice, I stay at or above 60fps because the collision detection isn’t great with larger timesteps. While it’s nice to be able to use Serial Loops to iterate more naturally, it’s still rather inaccurate and slow and I’m not sure what a better solution would be here. If there’s a way to have some sort of native collision detection node, one that can more efficiently look at all points at once, that would be welcome. Beyond that, having access to “sub-steps” I suppose will help a bit… but would still be slow.
In the sim there is one place where loading an external “data file” for a data-driven simulation would be very useful. In the sim I had just 4 particle types which means there were 16 different force values I had to specify and hook up to describe the interaction between each type. I wanted to go with more particle types but setting up the graph for that became too much work. Being able to load a .CSV with those values somehow would be very nice at some point.
When doing anything with particles I try to stay within the Point domain including through to Rendering. In Cycles that means I can render the pointcloud directly without instancing spheres/icosphere geometry at all. It would be nice to complete pointcloud support in Eevee
Motion blur seems to work now in many of the sims! Which is awesome. However, I think in some cases it still does not. Can the team document the exact requirements for in-camera motion blur when using Cycles?
I don’t think i could come up with an exhaustive list, i’m not that familiar with Cycles.
One potential issue could be that cycles relies on stable point IDs or instance IDs between one frame and the other to do motion blur. Changing the set of particles might create new IDs that cause motion blur to stop between frames because Cycles can not recognize a particle as the same.
The first thing I tried to do as a small test of the new nodes was to create a simulation for a body with a bunch of notes attached to it (as part of a larger character design I was working on). The node setup calculates the velocity and acceleration of each note (taking Delta Time into account) and then uses a Second Order System to make the acceleration smoother and more dynamic. It then uses these forces to drive the rotation of the notes, making it seem like they are subject to aerodynamic forces (the simulation is not physically accurate but it gets the job done)
If there is one thing I had a bit of trouble with, it was juggling between the different transform spaces. I had to first translate the note position from local to world space, and then once the acceleration was calculated I had to translate it back to local space, which involves some awkward vector math. There could be a built-in node to do these transformations (between object and world space), but ideally there should be a native Matrix socket type (like in animation nodes) which would make these kinds of calculations a lot cleaner.
One bug I’m still waiting for a fix on is the fact that attributes can’t “skip” the simulation area. In my case, I need to know the Normal output from the “Distribute Points on Faces” node to properly instance the notes, but I have to unnecessarily pass it through the simulation area, even if it doesn’t change over time. If I try to connect it directly it just reads all zeroes.
I’ve worked with simulation nodes quite a bit in the past few weeks, and I’ve actually had a fairly smooth time with them! I made an advanced particle physics simulator as seen here: https://twitter.com/HotdogNugget/status/1664090436498255872
This system does use delta time for verlet integration, and it works great! I’ve set up collision detection to work with either creating n^2 points, or just using index of nearest for fast (but inaccurate) collisions. With some further optimizations using index of nearest to skip points that aren’t touching anything, I was able to get it to reasonable realtime performance even with the more accurate n^2 method.
So far, my only setbacks have been regarding bugs that I assume will be fixed sometime soon. The main one is that having the timeline window open alongside the 3D viewport drastically reduces performance the longer the simulation runs. I’m not totally sure why this is the case, but for now I’ve just removed that window from my workspace.
Probably one of the best improvements sim nodes could get right now would be built-in substeps. Right now, the only way this is possible is by putting everything into a nodegroup and modifying the delta time. This is a bit cumbersome and still has some issues, so it would be great to have this as a built-in feature for anything physics simulation-related.
Another feature that could be handy would be a node to sample a meshes attributes from the previous frame. Right now, this requires plugging the mesh geometry into the simulation output and sampling the attribute by index from the previous frame’s mesh from the group input. This makes it harder to have more compact nodegroups for larger functions, as anyone using the node would still have to manually set things up. I don’t think it would need to go further than one frame back though.
Thats about it! sorry if I rambled a bit!
Another sim nodes project I worked on was a water ripple simulation: https://twitter.com/hotdognugget/status/1657917224924090368
Sim nodes works great for these kinds of things! ( though this setup would’ve been improved with a substeps option )
Yes, I believe there’s something related to changing id or some other aspect but I’m not sure exactly what it is. A quick test where new points are continually joined in seems to indicate it’s not quite the id though (points with the same id are not being blurred seems like)?
Using the special velocity attribute (that exact spelling etc.) does seem to help this case. But it would be good to know the exact mechanism that is causing no blur. Making more folks aware of this attribute and having them use it by default might be good if possible: Attributes — Blender Manual
A nice thing is that it looks like neither Baking nor Caching is required to get motion blur to work with GN like it was for particle systems and simulations in the past! Is that just a happy accident for now or can we start depending on that?
TLDR: Trying to create proper boids, but failing due to missing “LOOP” functionality in geometry nodes
I was trying to create a boid simulation, but failed to “do it properly” since I don’t know how to get all points that are within a certain distance of a point. It seems to me that the most straight forward way of doing that is in a loop, which does not exist in geometry nodes (yet).
Erindale on twitter set up a boids system if you’re interested! Definitely feasible without loops, as accumulate field is really all you need.
This site won’t let me link to twitter unfortunately, you’ll have to search it up yourself.
I believe the setup is using index of nearest which would explain the slight jittery change in direction of the boids, since it does not seem possible to sample the X amount of nearest boids velocity. I would love to be proven wrong though . I checked in with Simon Thommes as well, and he also believed that lists or loops would be needed for this type of setup.
for reference here are the nodes required for getting the net velocity of all particles within a given radius. Keep in mind that this gets exponentially slower the more points there are, since every point is going through every other point in the cloud and summing up the velocities within a range.
Not exactly the best usecase for simulation nodes,
but I am currently doing an internship at Faber Courial and created a roof generation system in geometry nodes. It creates roofs out of simple geometry:
It uses sim nodes to run over each face of the base mesh and cut off the overlapping parts of the raw roof. For it to adapt easily for different face counts, I created a script, which goes through the timelines frame by frame (defined by how much faces the base mesh has).
So after processing i have a cutout roof. I used this aproach rather than the bake cache operator, but it always returns {'PASS_THROUGH'}, maybe its not yet supported.
I also created a second script, which bakes the sim nodes and applies the geometry nodes modifier. It links with our inhouse export addon, so the baking and exporting is one click.
I look forward to Serial Loops, which would make the process a lot simpler (:
