Agreed. It’s better not to start inventing new conventions in this case. It comes to mind a few projects that tried that and it back fired.
Complexity can be hidden for the new users in more high level nodes aka group nodes, that hide the low level stuff, of course in the future blender would need to include some, but with the asset browser I think it’s possible in a near future.
Talking of complexity, I imagine that when we have “simulation” nodes, they too, will be low level blocks that will allow to build various types of simulations. So a fuild simulation would be various node that can be “hidden” behind a group node, so new users can “play” with the high level node, but more advance users can tweak the simulation.
Complexity can be hidden for the new users in more high level nodes aka group nodes, that hide the low level stuff,
I think it’s important to give our feedback about this because dumb-ification can be introduced on a low level in the future. ex: instead of using vectors with radian to represent EULER angles, we’d use a special “rotation socket”. It is planned for 3.1 afaik.
I think that the Blender community needs to decide whether nodes are:
- A way to bring in people who haven’t programmed but need a way to build complex scenes.
- A visual language that mirrors programming capabilities - to what end vs programming?
- A fusion of these that has constructs that are approachable and constructs allow for complexity as your learning progresses.
Not directed at your comment @kalmdown, I thought I would mention a few things that will help the conversation move forward, because it’s easy to get into a code/node mutually exclusive situation, which they are not:
There is a common misconception that nodes are a stepping stone into programming, or that a node interface is “programming for non-programmers”.
Looking at prior art in this field, many powerful graphics tools use nodes for their speed of creating image / data pipelines.
I am mentioning the tools below, not as to say what GN & Blender should do, but as a way of discussing how DAGs are used in industry, and why they are not ‘programming for beginners’.
Tools like TouchDesigner, Nuke, Shake (RIP), Houdini, Fusion etc don’t come from the POV of: “The nodes are a way of simplifying coding”.
Many of these tools allow both code scripting & graph interaction. Some even go full circle, and allow the node graph to be expressed as a script!
The drive towards a node based graph interface is to make it fast to try out ideas, rearrange, create, with extreme flexibility, and present that in a graphical way, which is based on flow diagrams. (which are used in software land all the time- take a look at doxygen graph visulisation.)
It’s not about making coding simple. Nuke users don’t think: “I should do this whole thing in code”. They use the node tools to get their job done, and if needed they can script nodes in order to get the system to do what they need.
There is a good example of Nuke used for Iron Man, where the compositing artist builds the iconic Iron Man HUD internal helmet. (both 1 & 2 should be required viewing)
4min mark is where the discussion moves to using scripted expressions to turn off motion blur if the 3D objects are moving below a threshold.
Looking at the node graph that is built for the Iron Man HUD, no-one would think “we should have done that in code, but we are not smart enough”.
So lets move forward with Nodes as a tool in their own right, and accept that it’s not a case of or, but rather nodes can be used with scripting/coding to achieve what is needed by the creative Blender user.
11 Likes
This is really well put together 
To me GN nodes do not represent programming, hence why i find “for Each” so out of place when blender’s design forward is opensource-simplicity-approachability for end users.
Main reason why i find houdini so complicated to use, with million of node’s that i have no idea what they do cause they have weird names, some make sense and others make no sense.
The problem, is that if you don’t have low level nodes, then some stuff becomes very difficult to produce. Houdini is complicated, and that is where it power resides. In the latest version you can see lots of “canned” nodes graphs that users can just use without having to know the low level stuff, but still giving power to the advance users.
3dsmax tried to take the simplicity route with MCG, and it hinder the usage. For power users there were missing stuff, for beginners it was still too complicated… But I’m a TD and SWE, and I’m used to all this stuff so my view may be bias, but it’s just my 2 cents.
3 Likes
I initially suggested other names than ‘loop vs geometry loop’ because I thought the names didn’t really make the difference between the two sorts of loop clear.
I agree it might be better to stick to existing conventions. But then it might be better to go back to ‘loop’ and not ‘for’. The name of the construct is a loop. ‘for’ is just the keyword in lots of languages. Also ‘for’ has an ambiguous meaning to non programmers.
But at the end of the day I don’t really care much one way or the other. I do like ‘for each’ for the ‘geometry loop’ variant, so that’s maybe in favour of using for.
1 Like
In light of the recent contributions to this discussion, I am in favor of “loop” & “for each”.
My reasoning : “loop” is pretty clear both for programmers and non-programmers. It is also a long-standing convention. As @Alexandermitchell pointed out, geonodes are not a dumbed-down version of programming. They’re technical by nature and there is only so much we can convey with a single keyword. So it might be wiser to rely on documentation and tooltips to clue in the rookie user about what they do and how they should be used.
“for each” sticks to the “verb first” convention in use in geonodes, which is very descriptive and helps the user parse a node tree.
5 Likes
Now I’m not a native english speaker, but I’m pretty sure “for” is not a verb 
As others have pointed out “for” can be ambiguous. It can be used in a lot of different ways. Personally, I’d vote for “repeat”. It’s still precise, not ambiguous and non-technical so easy to understand. And - let’s be honest here - “for” is just used in programming languages because it’s shortest, and programmers are lazy 
(hey, I can say it, I am one). Fortunately, the header in the node is not limited to only 3 characters.
4 Likes
Really ! I’ll have to double-check that with the academy if you don’t mind.
What I meant is that the motive for “verbs first” is to present the node tree as descriptively as possible so that it can be read out loud step by step (that’s my understanding). As far as I know this is also the rationale behind languages like Python : mimic natural language as close as possible, so as to be read more easily.
Since the loop construct is not an action in itself, and more of a container for actions, the most natural keyword I can think of is “for”. “Repeat” has also been suggested but it’s rather unconventional and I think there’s value in sticking to conventions. I hope that clears it up
@Alexandermitchell super looper has my vote
2 Likes
Developers can call a looping node “super looper” as much as I care.
I am only interested in what the system can acheive, and how cohesive it is.
Names of nodes tend to be quite personal to the system. TouchDesinger has quite a few bizarre names, so to do most node based apps.
Its up to the user to learn how everything fits together, and the developers to work out a system that is flexible enough to achieve what users need. edit devs tend to be artists as well with creative apps, so they are also stakeholders in what capabilities the system has.
Artists are a smart bunch. One has to be quite intelligent and dedicated to be a creator in 2021.
I think we can all handle calling “loop” “repeat” “itterate” etc, etc.
5 Likes
It could be interesting if Geometry loops could be used to create assets (for scattering).
E.g. … a leaf generator could be like this …
I would use a Geometry Loop to create some leaves. Like that …
Points of a mesh line would be used as an input. (Not sure how to vary “Leaf Size” in moqup. A setup with a noise would be plugged here.)
The Geometry Loop is “Create Leaf Asset”.
After a leaves-asset is generated, leafs could be used to instance the leaves for tree generation. Just like one would instance custom modelled leaves out of a collection.
In the same way, rocks or pebble-assets could be generated.
(To make it work, I guess one has to pack each Geometry the loop generates into one instance. But, for this purpose, a ‘create instance’ checkbox for the Geometry Loop would be useful.)
2 Likes
We already talked in the chat with some devs about a way to generate multiple assets from one generator, the main idea found (i recall) was a node that generate an instance list 
2 Likes
Agree with this point of view.
This is a dev forum, with many people being developers. To have nodes be a tool in their own right user research needs to be done on how all users, not just those who spend time in dev forums conceive of complex projects and could see using nodes to create them.
It would be nice if you show some quotes.
But it seems that Geometry Loop could do the job.
( Each generated Geometry needs to be instanced. )
2 Likes
But does Geometry loop allows this?
I’m not sure I’ve understood it enough to answer this question.
But if the answer is “no”, solving most common use cases is imo not a good argument as at the end, we’ll need something more complete.
That probably has been said in the previous numerous replies, but the “power” of a loop is mainly the ability to manipulate at a given iteration what has been calculated at the previous one (same principle as “reassign” in Animation Nodes).
Great Post, Totally agree here.
About the naming of loops, and nodes in general, I think the important thing is to stick with a naming philosophy and then use tooltips and very well written docs to better explain what nodes do.
I can simplify and see two main scenarios:
a) the Naming is primarily based on coding conventions, with clear tooltips explaining to non coders what nodes do. Eg.: “For” “if” “float” , and then tooltips , even very verbose and docs that carefully explain what a for loop does or that a float value is a decimal number.
b) Naming based on practical use, whit tooltips for programmers. Example: a node called “decimal value” could have a tooltip or a documentation that includes in the explanation “this is basically a float value”, or a "Repeat " node with a tooltip that basically says “This is the equivalent of a for loop”.
I use to live in both worlds, when I was a kid I used to struggle with technical words (expecially in shading, I hated and loved mental ray) and complaining that the software looked like it was designed by engineers for engineers and not for artists.
This was so frustrating than I had to take a digree in Software Engineering.
Now I don’t bother having technical coding words describing nodes, but I think in general they should have intuitive names that make sense and clear reference to technical docs and tooltips. (Case B).
I would be happy in both cases as long as there is UX consistency across the whole software interface.
About naming: if “For Loop” isn’t clear to Blender users because “artists are not programmers”, then by that logic, “Float” should just make objects levitate.
27 Likes
7 Likes
Let’s not hit the ceiling, or drop to the floor over this. It’s not absolute.
Ok, I’ll let myself out.
7 Likes
Round up and reflect, this is the only way we’re going to rebound from this
(risky I know)
1 Like