Does anyone know a a way to make a “for loop” of some type? I want to make a number of modules, and have them be effected by a value in the modifier window. It seems that there should be a way to do this with attributes or drivers or something. I think a for loop is the missing piece to generating so many different things. That was the power of OpenSCAD. You could make “modules” (the equivalent of nodegroups) and then reference them in other modules, or your main code. To generate things on an offset from each other, you could create a for loop, making a variable, and tell it to create a module until x is equal to an input number. I wish such a feature could be possible in blender.
It could be dangerous, and have a chance of crashing easily if you set the limit too high. But this such is an essential feature.
This is what separates geometry nodes, and actually generating. Sure, you can make points and use randomness and use random objects where they are. But that’s not full generation. Full procedural generation means that once you do it once, you never have to do it again.
And I’m not talking about arrays. Arrays are nice, but they can’t be used to do a any task. Just creating a duplicate of some geometry.
The primitive nodes though is a giant step toward Geometry Nodes being capable of actual generation. You can boolean model now, it is a bit on the basic side, but you are no longer just modifying existing meshes.
In the case of primitive nodes being unable to produce instancing for points, it seems like the way to solve it would be the ability to convert geometry data to an object (perhaps via an input into the object info node). It would do for meshes what the attribute convert node is already doing for properties.
Yeah, exactly, we’ll add a way to instance a geometry directly here. I don’t know how soon that will be, but it’s definitely planned. Personally I’m really excited for it.
We haven’t really written anything down for this, it’s just something we’ve all agreed we want to do. In terms of design it’s pretty straightforward anyway.
I like how geo nodes are getting rid of the old messy way of using a hair type particle system for any static shapes that you need lots of. Now if you could make the trees procedurally, that would be a whole new level. I hope curves come to GN soon.
1 Like
Renzatic
(Professor Emeritus Billy H. Wafflesmith XIV Esq.)
494
The development of Geometry Nodes is exciting and the tech improves at a mindblowing speed.
But the decision to follow the style of the shader and compositing editor will bite them hard.
To stuff all the UI and options into each node, instead of having a simple node with the properties in a designated properties area, will be a nightmare. It’s a bit short-sighted to think that if it works for shader nodes it will work for geometry nodes. Just looking at all those options Houdini is offering per node … this is something they will never be able to put into a single small node. There will be countless UI discussions that will drag for months or years of how to do the UI for those small nodes. To have the properties somewhere else, to use custom curve widgets or sortable lists or whatever – no problem if those options live in a properties area. But good look squeezing those option directly into the nodes.
Really curious how they’ll do solver nodes. Either they strip them of countless features for UI’s sake and make them dumb or really low-level, or there will be enormous mega nodes. Time will tell.
This is a good point about Blender nodes. Houdini offers pretty high level nodes and a panel for the UI. Blender nodes are a mix of low and high level nodes. Remember that the node UI is exposed in the tool panel too. So you can zoom out, click on a node and edit it in the panel.
The same is very true for compositing nodes compared to Nuke that expose settings in a panel.
maybe at some point the node interface will change in blender, I like both system, in blender it’s quite minimalistic and it forces to keep things simple. That’s indeed a limiting factor when you want to push things in details, also trees in blender tend to go messy very quickly unless you add a bunch of nodegroups… Probably if it’s going to change that will be for all editors. I can imagine that could be a lot of work , that’s maybe why the design hasn’t evolved that much from elephant dream. But BF has more ressources to make such change nowadays.
Agreed. Blenders node trees tend to be visually messy the more complex they get. Love the clean, straight-lined, and easy to read structure within Nuke. A shit-ton of options in the properties area plus way more freedom with custom widgets like the shuffle node for example.
I just fear the dev-team will waste a eternity trying to agree on a simple and tiny UI for complex nodes. I can’t imagine a solution for a complex solver node that doesnt look like a mess with Blenders way of putting all controls directly onto the node itself.
And a hybrid solution where some settings are in the sidebar and some settings are on the node is even worse. Nobody knows about the alpha settings of the image node in the sidebar, they are secretely buried there.
Perhaps, but having no options exposed in the node at all is pretty annoying as well. It is such a pain to go to the panel in Unreal for example just to edit a number in an value node.
Maybe it would make sense to put the most frequently used things into the node itself while putting other things into the panel. Of course a lot of people will complain because their favorite thing is not in the node.
How does Nuke, Houdini, ect… allow you to drive the parameters with the output of other nodes?
I would think you could choose to ‘expose’ a value as a socket (which would then be added to the node graphic), or are things just not as flexible that way?
You already can hide or show unused sockets with ctrl-H. It might be more useful to be able to pick and hide at will from the properties window, with a hide button or something.
In the sidebar, you can choose to show or hide the values by clicking the standard eye icon. When hidden, the socket disappears unless it is already connected, in which case it stays but is greyed out. When shown, the socket is displayed as normal.
