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.
1 Like
Brrrrh …
Dona nobis pacem. 
1 Like
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!
4 Likes
Screenshot removed following:
2 Likes
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
5 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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?
1 Like
They’re basically separate topics as far as development is concerned.
1 Like
Quite a strange decision to introduce users to simulation loops before the more simplistic loops, isn’t it 
3 Likes
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.
5 Likes
I also support the idea of introducing Loops before Simulations in GeoNodes.
5 Likes
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.
1 Like