Can you give an example of a use case where you would use that?
Can you give an example of a use case where you would use that?
Sure, here’s an example: doing math operations that use the iterator index. This is a fundamental concept in loop operations across multiple contexts, not just in programming but also in node-based systems like Geometry Nodes in Blender. The use of the index in math operations can provide enhanced control over the behaviour and attributes of objects within the loop.
Do you need example on why mathematical equation are useful in geometry node as well? I could give you some example on why math is useful of course 
“why on earth would we need this”
for i in range(nbr):
...
“when we can do this”
int i = 1
for _ in range(nbr):
i+=1
...
is that really the question? i don’t see why there’s any resistance on including the iterator within the loop interface itself. it feels like re-inventing the wheel
4 Likes
Conviency vs Minimalism, I think you could argue for both.
Edit: I actually like the direction of keeping things clean - just for the basic nodes.
Users could just add a math (add) node to iterate. But I see your point too ofc
I’m still heavily leaning towards my own proposal however, doesn’t seem it got much traction, so if we’re gonna do this max_iterations thing, please go all the way, provide the current iteration index, and provide the exit iteration index. if we’re gonna help people, help them all the way.
5 Likes
Finally this is possible with Serial Loops!
1 Like
It doesn’t have to be by default, but I certainly believe it is something used very often. I picked up the patch today and played for a short while:
A simple soccer ball; the faces are getting extruded in patches based on the original geo’s face index (a truncated icosohedron). I’m just comparing the iteration number and the iFace attribute I set.
I’ve seen it in other software where you press a button and it will generate the iteration count and the iteration sum as attributes, so they aren’t there by default, but can be with ease. In my opinion thing it’s a UI thing, we can do this manually each time we need them, but functionality wise I feel they basically go hand in hand.
Currently, we’re leaning towards just not supporting breaking out of the loop in the initial version to keep things simple. Support for breaking can be added when we see more of what people do with these loops. It’s still possible to “fake” breaking using switch nodes.
Enter determines if the loop is entered, if false the input Geometry is passed through to the output
Exit determines if the loop is exitedenter and exit are not as ambiguous as break and output previous and it allows people to build
I do agree that those terms are less ambiguous. However, I also feel that this approach makes it harder to use the loop for most valid use cases. Also they make the whole design dependent on being able to stop depsgraph evaluation which is a whole topic by itself. Building infinite loops is just too simple.
Note that in the current patch I renamed “Max Iterations” to just “Iterations”. I don’t agree with that it brings little to the table, even if we have breaking.
please add loop index as a default input
I’m not generally against this and we might add it at some point, but likely not in the first commit. I have yet to see a compelling enough example where the index is used for use cases where serial loops are the right solution. Every time you iterate over e.g. vertices or islands or whatever, serial loops are likely not the right solution. Due to their serial nature, they just can’t offer great performance as the number of iterations goes up.
Serial loops are designed for the use cases where you previously had to build a long horizontal chain of nodes. For everything else, they are likely the wrong solution. Of course, every one is free to use serial loops for all the other cool use cases as well. I totally understand the temptation and I’m not even suggesting that you shouldn’t do it. It’s just not something I can recommend people to do in production when the number of iterations is large, it’s just gonna be slow.
For parallel loops, whose purpose is to actually iterate over e.g. vertices, adding the index is a much more logical design decision. We will adress those use cases separately, but not for Blender 4.0, but likely in the 4.x series.
15 Likes
Seems like people are just desperate for loops of any kind…
Regarding serial-specific applications: I’m trying to build a group to generate a catenary curve between two arbitrary points. Due to a quirk of the math, the simplest way to do part of the calculations is by iteratively finding better and better approximations of a value (details).
That seems pretty easy to do with this system. The lack of a “break” function may make the precision of said approximation a little wibbly, but for an artistic application that’s not a big deal. Shouldn’t need a super high iteration count either.
The part I find confusing is the “Output Previous” input. I understand that it lets us switch between while loops (min. zero iterations) and do while loops (min. one iteration), but the term “Output Previous” doesn’t have an obvious connection to that concept…
Actually, the most intuitive solution may be to just ditch while loops and enforce do while structure. “This block will run multiple times” is simpler to explain to non-programmers than “this block will run some number of times, possibly including zero,” and if you really need while functionality it’s very intuitive to just. bypass the first iteration. (at least I find it intuitive–not 100% sure others will~)
2 Likes
FYI, the current patch is available here: https://projects.blender.org/blender/blender/pulls/109164
It will likely be merged early next week when I’m back at work.
6 Likes
What happened here? 
These nodes implement loops. Everyone knows them as loops, everyone will call them loops, everyone will think of them as loops, most other node based software calls them loops, and a new user who will be looking whether GN supports loop will open the add node search menu and search for a term “loop”, or open a google search and search for something like “Geometry Nodes loops” to see if they are possible.
So why in the world are these nodes named “Repeat”? If someone asks what do the repeat nodes do, the very first sentence of the answer they will get will most likely contain the word “loop”.
7 Likes
See here for the rational behind the name “repeat”: https://projects.blender.org/blender/blender/pulls/109164#issuecomment-972479
Name: “Repeat” suggests the main target for this function, and it is more accesible/simple concept than Serial Loop (or even Loop)
1 Like
That sounds like the very opposite of rational.
I mean terms like Euler, Quaternion, Integer, Field or RayCast show in geometry nodes. If someone is expected to use what is essentially a visual scripting language with all the mathematics involved, they will most likely be already familiar with the term loop. Let alone the fact that GN will coexist and interoperate with Python in the very same 3D package, and Python doesn’t have “Repeats”.
This is just nonsense. The right user level of abstraction has to be decided for the GN as a whole, and then adhered to. We can’t have some of the node and node setting names catering to kindergarten while others catering to computer science students within the context of the very same feature.
This is once again just such a Blender thing to do - there being very strong industry standard of something and someone at Blender dev team having an urge to be different just for the sake of being different.
2 Likes
I think the goal is to avoid people using these serial loops for when they actually want to use a parallel loop (which is much more common). E.g. when you want to do something for every vertex in a mesh, or every curve etc. you do not want a serial loop. And I guess that once we have actual parallel loops, that they will be called as such.
Serial loops are really only useful when you want to e.g. repeatedly execute a node group. Hence “Repeat”.
TLDR: These are not the loops people think they are, so they shouldn’t be named as such, actual loops will come later.
10 Likes
The decision to drop “Loop” is definitely a bit odd, but “Repeat” does suggest the intended use case much more directly. As long as it turns up in a search for “Loop,” I don’t think I’d have any trouble with that.
4 Likes
Then what is wrong with serial loop & parallel loop as names?
6 Likes
In this context it makes more sense (it was not mentioned in the task), but still… I thought looping over individual elements like vertices is already implicit with fields. As in if you have set position node it loops over every point in the field and sets its position from the source field.
So if this is a serial loop and there will be parallel loops, what will be the use cases where I would want to use parallel loop? Or rather what would be the uses cases where I want to use serial loop?
Just thought of a case when Index might be useful. Suppose you want to procedurally generate 10 tufts of grass to scatter across your scene with Instance On Points. You want every tuft to be different, so you make a serial loop that generates tufts randomly–and you use the Index to seed the random number generator.
Basically, you want to use serial loops when the iterations depend on each other. And you want to use parallel loops when they don’t.
A good use case for a serial loop is physics. E.g. you want to resolve collisions between particles. In one iteration you push them apart a little, but then you need to iteratively repeat the process to actually get rid of all the intersections.
@SiriusBizdness Just gave a great example of when you use a parallel loop. Instancing stuff on points and doing something with each element. That can be done in parallel and it’s precisely why a serial loop should not be used.
3 Likes
Sure fields are already executed for each element in a domain. But then you’re limited to what the node that the field is executed in can do.
A parallel loop allows you to build your own, just as performant, Set Position node, but with all the control.
1 Like