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.
If I know what a loop is then perhaps. But if I don’t then probabyl not. At least for “Repeat”.
“for-each” is easy to search on the internet, so that would be a good name.
“Repeat” not so much.
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
is there a way to upvote the issue?
Well…Decimal and Integer would be more non-programmer friendly…
Decimal … is not float
For an artist…decimal is float…and why should they care? They don’t {want} to choose between these (integer/float(ne: decimal)). …Should the user care? Can’t the system mediate? That the system makes the user care is a design failure. Could have a setting - precise/not and let user choose that and see the effect on their render/animation.
Where is the value in having the user learn programming distinctions? I know the distinction between the two from programming myself but can’t see how a user would care. What mental model will have the most value for most users - developers or artists?
We are talking about the most basic, easy to learn programming terms for people who are learning how to work with 3D computer graphics. If anything, the devs. should not make decisions based on the assumption that artists are like little kids who can’t learn anything even remotely complex. A simple concept of a group node executed x number of times is far from something that an artist would not be able to learn, and that is actually a little more complex than figuring out what a float is.
Generally, the artists who are steadfast in not wanting to deal with any technical stuff will either stick with 2D painting/sketching programs or avoid computers altogether (ie. paint and canvas).
Fundamentally a number is a number and historically I think integers are separate from floats for memory reasons. So yeah… However I see direct user value in choosing between the two, such as building an interface for a rig (or for a geonodes modifier) where you want to expose a property as an integer. This is also true in the case of the RGB triplet which is basically a vector3, except it does not go in the negatives.
Most conversions are done implicitly already and there are conversion nodes if you need explicit control (round, etc). I think it’s a rather sweet spot !
There was a discussion about this a while ago (not saying absolute truth was attained, but it’s worth reading)… not sure on which thread it was ?
I disagree that artists that don’t want to learn technical stuff want to stick to 2D. What they would like is a SW that minimizes the amount of technical knowledge required to accomplish their goals. And they are not little kids. What I am saying is that there is little value in programming distinctions. If the user is putting nodes together, really all they care about is that they are hooking a number up, not whether it is a integer or decimal. That is something the software can deal with by looking at the pipeline and a user’s choice of precision and decide whether to cast everything or parts in integers or floats.
The more complex a setup gets, the less true this statement becomes.
I’m convinced that having the integer restriction on certain numbers makes things more intuitive not less. If you use a single number representation, you quickly run into awkward questions like what does a cylinder with 31.5 sides look like? Or what happens if you create 4.234 copies in an array? Can you have a texture with 1023.8 pixels? How about applying 0.7 levels of subdivision? Differentiating between integers and floats is not an implementation detail leaking (the naming is), it’s a lot more fundamental thing that exists in the real world.
Wanting artist workflows free of programming conventions is an admirable goal, but we must differentiate between leaking implementation details, and inherently useful concepts which also happen to be used in programming. Both loops and this off topic integers vs reals distinction fall into the later category in my opinion.
Yes, there is. You can learn concepts from other programming languages if the terms used are the same.
Why not rename fresnel to angular reflection intensity falloff? Or inverse kinematics to follow child bone. That would probably be easier to understand if you have no experience with the mattwr at all. But it would also rob you of the pissibility to google for these terms.
Using terms that have an established meaning make it easier to learn.
You are essentially saying that an artist is a neural network that experiments and learns. But due to the small difference at the beginning, by the end, the error will be fatal. Learn from the documentation, do not rediscover things that have already been researched
I propose we go back to discussing loops in geometry nodes instead of endless niggling about minor semantic details.
Don’t get me wrong, it’s an interesting topic. But it is not really on topic anymore.
Or maybe all that needs to be said about loops has been said, and this thread can be closed for now.