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
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.
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 ).
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
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.
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.
While I agree with you in principle, lets not overcomplicate things. Itâs just a loop, not rocket science
I guess if itâs called for-each or repeat youâd understand itâs some sort of looping construct.
Either way, I donât really care what itâs called, I just though giving both variants (nearly) the same name would be confusing.
Graphical programming is a very old idea, going back decades. I can remember Prograph on the early Macintosh, also LabVIEW from National Instruments, and nowadays you have Scratch from MIT, and Blockly from Google. Youâll notice the latter ones are targeted more at children learning to program, rather than professionals trying to get work done.
The whole concept has fundamental problems which have never been solved. Learn from history and understand its limits.
This is a rather defeatist way of looking things donât you think? Can you actually list these fundamental problems which have never been solved?
Sure, textual programs are more portable in a sense, because you donât need the UI code to display them, and text editors are quite universal. But this just the same concept you see with graphical applications vs command line ones. Iâm quite happy with text based programming, but having a domain specific language thatâs specific to blender be represented by a node tree is completely reasonable.
And itâs not like textual programming is perfect. Functional concepts like piping and map/reduce have been used for decades now to make textual programs more graph-like, because itâs easier to understand a flow of information that way. The programs you write, even the ones using text, are in essence graphs anyway and the compiler, parser, and all other tooling you might use treats them as such behind the scenes.
You can even translate any graph based program into a textual representation or the other way around and do version control on the text if thatâs what you are missing. Projects like KiCad already do this just fine, you can diff electronic schematics and PCB designs without problems.
Lack of tooling is not a fundamental problem, itâs just an obstacle to overcome.
LabView is still heavily in use today in certain fields (for better or worse), and there are plenty of other expensive industry tools like IDEs for PFGA design which rely on node based systems.
Keep in mind that we are simply talking about the ability to iterate a group of nodes x amount of times, which is far from emulating a programming language. In fact, the devs. are deliberately implementing safeguards in the general scope of nodes so people donât try to do things like resurrect the BGE.
From my experience so far, Everything Nodes feels nothing like writing a Python script in the text editor, and any idea that artists should just learn to write code if they want to automate anything is silly. Geometry Nodes now is essentially âCyclesâ for geometry, I do not recall having to deal with syntax or having to look up functions, and there is no hunting for errors in things like variable declaration either. There is also no need to figure out algorithms, many of the nodes now do all of the math for you and artists can figure out how they work by just playing with them for a few minutes.
Finally, scripting in Blender is, last I checked, destructive. PC hardware is now at the point where we can look past scene creation as a rigid step-by-step process (that requires you to always have a complete plan before starting).
As long as you think about it as a notation for expressing data flows, you have less chance of getting into trouble. As I recall, it all began with compositor nodes (which Blender actually pioneered), and youâll notice that has never had pretensions to get into full programming constructs.
If you want more than that, why not offer a general-purpose âscriptingâ node, and be done with it? Like OSL nodes in Cycles. Or indeed, I think, geometry nodes in OpenGL. Given that operations are per-vertex rather than per-pixel/sample, you might not need a specialist language like OSL, instead you could probably get satisfactory performance using Python.
I think a general purpose scripting node would be very useful. Though defining the interface would not really be simple I guess.
But having specialized looping as a node is very useful. And has been done with success many times before in other node systems (labview, mindstorms, to name a few).
Yes, there are problems inherent to node systems. Mainly versioning/source control. But none of those problems hinge on the existence of looping constructs.
I think what youâre afraid of is the greater risk of âspaghettificationâ. I.E. the node tree becomes a tangled unmaintainable mess. And itâs true that the more complex the nodesystem gets, the larger that risk gets. But the same is true for all turing complete systems. I know from experience that itâs possible to write spaghetty in any language, text or nodes. Thatâs no reason (imho, of course) to dumb down the node system.
could be done with an add-on! Reading the node data and serializing that is def possible. Once youâve done that you could even build ASTs and build a small scripting language that can be transpiled to nodes
).