Loops in Geometry Nodes [Proposal]

very nice concept but please stick to the conventions of all programming languages be they visual or code based (For, foreach, while etc.)

8 Likes

funnily enough there was a bug in the 2.80 betas that allowed you to place a collection instance inside of its source collection

yielding you such beautiful fractals

Avoid trying to turn node graphs into a full programming language. It’s not going to end well.

1 Like

If anything, Geometry Nodes in 3.0 feel like less of a programming language than the same in 2.93, I do believe the basic concept of a loop can be easily understood by the average artist (one input, one output, run the same string of nodes run multiple times before the execution can continue down the tree).

Now I do agree that there is no need to include everything that a language can do, at least not initially. It is better to start just with the proposals at the beginning (but with the flexibility to build out from there if needed).

4 Likes

I guess that’s a wrap, boys ! I’m not messing with prophecies

(in all seriousness, it does work pretty well in Copperfield, so why not in Blender !)

1 Like

Think of how you would put it under version control, and compare diffs to see what has changed. It just doesn’t work.

Now that I think of it, an 'export node tree to some textual format would be nice to have.

Json export/import for node trees? That way you could paste your nodegroups on forums…

3 Likes

while will make stuff like A* possible,
but we need to be able to exit when we reach the goal etc.

+1 for dodo’s design with a exit condition

2 Likes

Just because node based scripting is hard (but not impossible) to diff and merge doesn’t mean node based scripting is a bad idea. I consider Blueprint in UE to be the best scripting language I ever used, and it’s node based.

Houdini is the most popular node based 3D software out there exactly because it is node based, and despite that, it has functioning loops.

What you’re saying just doesn’t make any sense on multiple levels.

7 Likes

Well, it does make sense. Versioning is a problem with node based systems. I have been responsible for disentangling a 15 year old in house node based project once in I tell you it wasn’t fun. And it was impossible to see from the code which of the myriad badly archived versions was the newest.

Where I agree with you is that it doesn’t make sense is conclude from that that you shouldn’t do feature complete nodes. Yes, version management is an (as of yet) unsolved problem. But it has many advantages as well. That 15 year old system managed equipment with minimal hassle, and while it had grown out of control it had done so with relatively minor hassle, created by non coders.

Creating an unmaintainable mess is very well possible in any language, for that matter.

edit; hassle hasslor hazzlor hazz. whatever. I’m to tired to create consistent sentences ;-D

3 Likes

Version control and distribution of a visual programming language are such hard topics that it would best fit in its own discourse thread IMO!
A proposal on those one day would be awesome

Without any sort of iteration or loop function, the devs. would have no choice but to port the Array Modifier to nodes and build the functionality into existing nodes (which would be far less flexible and be more work than just having a node group type that does it for any setup).

I do not see why no should be allowed to have such powerful functionality because of the potential of additional work for 1 percent of the userbase (who are the ones with very technical workflows that might see more typing than modeling).

I know the philosophy is to tackle a problem without any influence from other software, but Houdini is really the holy grail when it comes to procedural node based 3D content.

Houdini Support multiple ways of tackling a problem. For example VOP nodes are more artist friendly and VEX Script nodes are designed for more experienced programmers.
And the two approaches can even be mixed.

This makes Houdini suitable for a wide range of users with a wide range of experience and is neither too overwhelming nor too limiting.

I would really appreciate if loop nodes and in the future even script nodes could be executed in geometry nodes.

2 Likes

Do you mean the looping behaviour could be defined in a script, referencing other nodes for the actual loop contents ?

@JanErik please remove all images from other softs :slight_smile:

1 Like

I’m also hoping for a script node at a certain time.
But I am expecting it to come much later in the development process.
The system as a whole isn’t yet mature, so introducing scripts right now would make a mess through different future versions of Blender. (i.e. scripts not working because of X or Y changes in GN “backend”).
And it would also hurt share-ability, which seems to be a recurring constraint (and a huge thorn in my side to be honest :laughing: ).

1 Like

in Houdini both things exists, a script node, very versatile not just for loops, where you can write code in a dedicated langugage and reference other nodes.
But there are also loop nodes, where everything in between is repeated
Both methods are nice, depending on the task and the user. I would stick with loop nodes for the near future, i guess a VEX like script language is a long term topic

1 Like

in H it seems that some node editors are generating code on the fly, the nodes are just visual representation of code, a bit like python block editor or the serpens plugin. These kind of concepts can’t be implemented as an afterthought tho. It’s a very interesting design choice IMO that leads to extreme flexibility

VEX is NOT a scripting language. Its more akin to a shading language with compute capabilities. It is literally a programming language that can also be represented as nodes (VOPs)

Do not mistake it for a scripting language like Python.

1 Like

Regarding the naming:
If you decide to name a for loop something different than “for loop” please at least put it in the tool tips.
It can be very useful to know the “real” term for a thing when researching how it works.
If you know the real name of the thing you can search for the term and find references to the thing in other contexts which often is useful.

An example: Before using Blender I used a different 3D app for many years. This other app had a voronoi shader node just like Blender but it was called something else. I knew kind of how to use it but I didn’t know that the math behind it was a voronoi diagram. Nor had I ever heard of the term voronoi diagram.
I only learned how to use the voronoi node to its full power when starting with Blender.
That is because only after knowing that the maths behind this node were called voronoi i was able to google what it was, and how it works on wikipedia and other non 3D soruces.

2 Likes