Geometry Nodes Loops - Created

Support Tutorials, Tips and Tricks
, ,
1

I think I might have made loops in geometry-nodes.

Loops are a much-wanted feature for geometry nodes, but the developers have been busy providing us with other amazing and useful nodes. This may be a workaround.

The concept is that 2 objects use the “Object Info” node to extract each other’s information, allowing them to create data that is stored for the next iteration. The main problem is tricking the evaluator into reevaluating the group every something. In this case, I chose to use the “Scene Time” node because it was easily available and would work reasonably well. There is only one problem with this approach: the possibility of a race condition, where the evaluator keeps going back and forth between the groups, reevaulating them repeatedly, back and forth, until the computer crashes. I avoided this by making the group’s output stabilize after 1 iteration of each group, and it runs fine.

To activate the group, I first clear the counter by activating File->Reload (Ctrl-Shift-W). I then move the timeline to any other position (in 1 hop) and the group iterates forward, which could be incredibly useful if this could evolve into particle systems or physics solvers, both high-priority tasks of the developers. The biggest problem is the loop building up so much geometry that it crashes the computer (been there, done that, had to reload blender 6-7 times during development). This neccessitates an iteration cap, making things even more complicated.

For the attached example file, I generated a cube fractal of cubes instanced on the corners of the cubes of the previous “generation”. I only let it go 4 levels deep to avoid crashing my computer, but you could go much farther by changing a single number.

The other scene in the file (Accumulator) was a test to see if things could work, and it has a simple accumulator (a reduce() for the programmer) looped in.

I don’t know what all blender versions it will work with, but I made it on 3.3.

Let me know if you come up with something better or take it in a new direction!
GN_loop_test.blend (1.0 MB)

Loop Demo-0
Loop Demo-01920×1017 255 KB

Loop Demo-1
Loop Demo-11917×1017 325 KB

Loop Demo-2
Loop Demo-21920×1021 287 KB

Loop Demo-4
Loop Demo-41920×1014 281 KB

8 Likes
2

Very cool! :+1:

Saw this entry for Nodevember that uses the same principle…

https://twitter.com/seanterelle/status/1590937785388920834

… unfortunately it seems as if the breaking limitation for this technique is that this only works in the work-space viewer - doesn’t seem like anyone has figured out how to “bake” the animation to use the renderer. :cry:

Would be great if this was formalized as it would open up a whole bunch of capabilities/possibilities.

2 Likes
3

Well, I hacked on it today and drastically simplified the interface. It now reads more like BASIC than golbedy-gook, and is much more flexible than before. Though the internals of the node groups are not as simple, they are much less error-prone and I can actually understand what’s going on. :laughing: Indeed, I didn’t quite understand what was happening with the last attempt.

I hadn’t realized it before, but you can actually use the geometry datatype to group several attributes. You can pass several values with “Store Named Attribute” and “Named Attribute”+“Attribute Statistic”, allowing several datapaths in one link.

One good trick of this setup is that all the important loop information (max iteration, current iteration, and more) can be passed on a single point. The geometry for the loop body has that point omitted, so it looks normal, and it’s added back in in the “End Loop” GN group.

The “To End Loop/From Begin Loop” contains that data-carrying point and the original geometry, allowing “End Loop” to know what the unmodified geometry and the loop data are. An odd thing this lets you do is replace the current geometry with an entirely new geometry, which could be empty. Before, you had to pass the loop data through the nodes that were looped, but now it can do anything it likes to the geometry without affecting the looping.

The need for this link is annoying and would be nice to get rid of with a native solution (but in the meantime, it makes for an intresting use case for portal nodes).

I might try to make an elementary particle system out of this, based on the one in Unity3D, but I’ll leave the physics solvers to someone who has more knowledge of physics. :game_die: :volcano:

Why version 2.1?: I tried to make these begin loop/end loop nodes before and dramatically failed, thus 2.1.

As for that, you could always apply the modifier before rendering, although that would be a pain to redo every time.

GN_loop_test.blend (1.6 MB)

4

Check out this script from @moshus:

Thanks!

1 Like
5

Made a short test. It did not work here because the loop from the file only updates correctly when pressing the play button not when you manually advance frame by frame by pressing this button:
buttontime
or when the script alters the frame (contrary to the other buffer feedback networks i encountered so far). Not sure why.

1 Like
6

Boom! :boom: We have geometry-nodes particle systems! Using the same Begin/End Loop nodes from above, I now have a particle system.

Based on the interface of Unity3D’s particle system, the modifier only needs hooking up to its repeater object and it will generate away. There is even support for multiple particle systems in the same scene, something that the original loops couldn’t do. Although it’s primitive, the system is already very powerful.

It is built in two parts, the particle generator and the particle renderer. The two are separate objects. The generator sits on a hidden object, buffering with its companion repeater. The renderer takes the point cloud produced by the generator, and after removing the data transfer point, instances geometry on them. The renderer I built creates volume via “Points to Volume”, but other implementations (that work better) are possible.

I also made a new loop-dealing node, the “Infinite Loop” node, which can turn the loop into an infinite loop, which you can restart with File->Save&Reload (Ctrl-Shift-W).

There are two scenes in the file. The “Particles” scene shows a simple particle system, without a renderer. the “Artemis” scene houses 2 generators and 6 renderers, showing how the generators can fan out to multiple renderers. The assemblage, a nod to the recently launched Moon rocket, Artemis I, is rather badly blocked out, just for something for the particle systems to come from (and it’s fun :smile:).

@moshus, I looked at my nodes (without the script), and it turned out that I had some unnecessary nodes that were blocking execution in a few strange instances. They’ve been taken out in the new file.

GN_particle_systems.blend (1.5 MB)

If someone who knows how the built-in Blender particle systems (not me) work wants to chime in on how the interface should work, please do!

4 Likes
7

wait, I was playing with Sean’s setup, can’t bake but I can render it.

8

Check Higgsas’ suggestion here:

Good luck.

2 Likes
9

I mean you can already render without any coding

3 Likes
10

interesting, store named attribute very useful in these situations then

1 Like