This would come together so well with my idea of a multi level circuit node board. please push this forward. Semicolon and curlybracket nodes could be added later.
Brrrrh âŚ
Dona nobis pacem.
Things like replacing an instance on an object with that of itâs corresponding numerical index value using just geometry nodes is not that simplistic. A loop node may help. I wonder if trying to make it fit all needs all at once may be holding it back. Maybe the loops should be dealt with like the modifiers are being dealt with. Break them apart and have multiple loops for different reasons instead of trying to make one âloop node to bind them allâ
a bit late to the party here, but coming from unreal i think their ForLoop node would work quite well within geo nodes:
for anyone unfamiliar, plug anything you want into the loop body and itll iterate from the first to the last index.
this way you wont need to worry about massive frames needing to encapsulate big node networks and whether you want to group off the body of the loop is optional. just my two cents!
Screenshot removed following:
hey - here is my problem - i have constructed a house, which is only based on the shapes of the polygon on the ground - now i want GN to generate a house from a set of different âgroundplanesâ. When i think of looping this, i would expect the groundmesh to go into the loopinput (Mesh-loop) - the meshisland index count would be the times the loop has to run - so 5 times for the picture - inside the loop my main âhouseâ-nodegroup would live and for every iteration of the loop random numbers (that can be generated inside the loop or outside and be fed in) would be used for the procedural generation of every single house.
As a user i do not really care about the names - i figure out the behaviour of the nodes from trial and error and remember the name - so if it is looper, loop, Iterator, InstanceMaker, Repeater, Mesh-loop, For-Each or Forloop should really not be the Question that is holding back this important issue (i see the problem with new users, but honestly the blender community is the biggest for any given 3D Application, everybody should be able to find answers on the interwebs). As i read through the thread and the main-question seems to be âHow to integrate it into GN while not beeing a Nodegroupâ i figured there is only one solution i see to please everyone- have a Input and output node of the loop and automatically place them into a frame - everything that is then connected to any of these nodes (of course not the output on the exitnode) would be automagically put into the frame - so of course you could place nodes within the loop all over your screen and your frame would grow with that, but that is the responsibility of the user to keep the layout of the tree readable.
I think that is also a good visual key that something is happening when by selecting a âloopâ from the menue a Inputnode-Connected-to-aOutputnode-in a frame is created⌠i prolly didnt think of sepcial cases and such but for now i only want my houses to work i could of course apply the geonodestree for the groundplanes and seperate them by loose parts - the nodegroup than works, but where is the fun/proceduralism in that when the director comes in and wants a completely different streetlayout
here is a mockup how i would like a implementation from a user perspective (and minding most things above ),
i understand that frames usually do not have the functionality with plus icon here, and i do not know if that might be the harder part on this, but it would be a nice to expand a node (or a group for that matter) into a frame that is not deleteable - it will throw a error when trying to delete - as it is not deleteable and nodes cannot be dragged outside the frame, it should be clear to a user that this is a layout for a loop or a group - clicking a plus again shrinks the group or the loopnode to their essential in and outputs
breaks and reiterations as well as in and output settings should stay in the N-Panel under âloopâ as animation nodes did it, and as blender handled that like since forever
please point out any shortcommings - or do not if it had been said over and over and reply by READ THE WHOLE THREAD
cheers
Hi, Thanks for the illumination - just a thought, what happens when you now collapse some nodes to a group? the straylines get their own inputs to the group. For myself i would consider that a plus also in geometrynodes as everything is tidied up that way - so in my opinion no straylines should exist into the Group/Frame that are not firstly routed through the input-node of the loop. There might be reasons not to have it that way ⌠but i for now cannot see the benefit of having it that âopenâ.
straylines that are rooted from somewhere into the loop (without going first through a Loop-Input-node) should show a red line, even if they have the right socket or are just a field - it helps in the longrun to read and think in terms of loops when there is a clear In and Out, i believe.
Actually, I was wrong; I reread the initial post, and Jacques explicitly asked for designs that use frames to encapsulate the inner parts of a loop.
Geometry fields would provide significantly less to no usability improvements.
I want to contest that. While Iâd agree that for the serial loop case having loop groups or frames would be the easiest. I think for the parallel case geometry fields would be much nicer.
This example for generating circles on a gridâŚ
⌠could just look like this:
another node that could be done with geometry fields would be a Collect node, that evaluates the same geometry field multiple times and joins the results, kinda like this:
These more descriptive, I guess implicit loops only really work with fields, I guess.
I think whatâs problematic in general is that there is already some form of parallel looping possible, as most operations are taking basically a list of points / edges / faces / instances and are then applying their operation onto them.
So maybe it would be best to introduce a generic system for lists and then make parallel looping work with that.
In your approach, a node which computes geometry data wo act like a field.
I played with your idea. Would this be a useful idea for a âparallel loopâ? Anyway, its fun.
- A new slot type which acts like a geometry-generator field. (Example uses rose color)
- A parameter (which would be a group input in the group-loop approach) which will contain a value (computed from field) is declared as a âholdoutâ parameter.
- There is a generator node which takes a geometry input and outputs a âgeometry generatorâ slot.
- The generator node collects all âholdoutâ nodes which are plugged to its geometry input.
- Finally, nodes which use âgeometry generatorâ slot inputs to create geometry.
A serial loop would require a geometry processor slot type, and a âprocess geometryâ node, which collects (and offers) âholdoutâ variables.
If this works, this would not be that different from Group based loops.
Are there plans for nested structures, like trees?
Or, would we have to create a loop group for each depth level of a tree?
There actually might be some potential performance issue for âloopâ. The node editor/geometry node perhaps is what we called an âinterpreterâ in the computer science area (it might be python underneath). If the loop is executed too many times, the performance overhead is very huge (even CPython itself has this issue). If JIT (just in time compile) is implemented, this might be solved.
But given the massive amount of time spent in rendering, little interpreter overhead may be forgiven.
I think repeat for each is a good middle ground because for the programmers searching the term âfor eachâ. Maybe their can be 2 different nodes that do the same thing, their can be a ârepeat nodeâ and a âfor each loop nodeâ that are identical in every way except for the name.
Inside of Houdini they have something like this, when you want to add a cube in Houdini you can either add a âboxâ object or a âcubeâ object into the scene that does the same exact thing.
Then you might have the problem where people might think that âdecimalâ would imply that the value would need to be less than 1 or have no whole numbers to be considered âdecimalâ.
Are loops planned to come bundled with simulation nodes or has this pushed further down the road?
Theyâre basically separate topics as far as development is concerned.
Quite a strange decision to introduce users to simulation loops before the more simplistic loops, isnât it
I donât think so, no. In some ways the design of generic loops is much more complex since there are more compelling alternatives. Constraints like âadvancing timeâ can clarify the design.
I also support the idea of introducing Loops before Simulations in GeoNodes.
Dear all, I am really new here, I just registered an hour ago,
the reason that I would like to join this discussion, is that I really want this kind of loop node happen, and please allow me to share my ideas:
What I propose here is similar to your ideas to let functions to repeat, yet hope it can be more simple and perhaps more consistence with the existing blender idea of âfieldâ,
here it is, no need to introduce a group or frame structure, the loop body can be outside of the Loop or say Iteration node (number 2 in the diagram):
1, shows the repeat times, can be an integer or a field, if integer it will be the number of times to repeat, if a field, the function should be a âfor eachâ iteration
2, is the newly proposed iteration node
3, is the loop body, which is plugged outside of the iteration node, can be framed or grouped depends on the users
4, is a tag to show which variable is transferred to the next time of the loop
I guess this may be more close to the original concept of the field in the geometry node, and lot of existing functions already working this way in blender Geo_Nodes.
Hope this may helps.