Hehe nobody posted this artwork that is using geometry node yet?
The artist did a fantastic work
really showing the potential
10 Likes
Thanks for working on this! Iâm loving nodes, and Iâm excited for the Torus mesh primitive to come out!
I have two bits of feedback - forgive me if theyâve already been mentioned
1 - I would love to be able to add custom labels to inputs on node groups - it would be much easier to keep things organized if I could have meaningful labels rather than just âvalueâ on half my inputs.
2 - This may be a bad suggestion, since Iâm not experienced as a modeler, but my workflow uses booleans with meshes, and when trying to figure out how to shape and place a cutter, I use a Union, which I then turn into a Difference. To help iterate, it would be helpful if the behaviour on switching the boolean node between Union to Difference would be to keep the first input geometry in the Geometry 1 input, and then the rest in the Geometry 2 input bank. This way switching between Union and Difference would not require rewiring, as it was when the Boolean node only had two inputs. Just a thought.
Thanks for your hard work on this!
2 Likes
Iâve seen a lot of magnificent works in GN, including this last one, itâs jawdropping 
However Iâm worried about one thing, anytime I did something with GN, if itâs complexity itâs small-medium I end up with a big horizontal tree, hard to read and follow and nothing is parallel so I cannot organise the sections comfortably.
I have three questions regarding this:
1.- Execution Order
One of the biggest flaws of Animation Nodes was that there was no specific execution order, it was just âfirst come-first goâ with a bit of randomness from the user perspective.
In other systems, and I will mention ICE because it was magnificent, but itâs not the only one, you have ways to organise the execution order, there is an specific node for that, and you can have separated things and execute them linearly or in a parallel way, but they will be executed as you wish, so you can make things depend on other things.
2.- Linearity
Right now if I want to work with several objects and have things organised in âpiecesâ and then have one main âflowâ to execute everything organised there is no way to do it AFAIK.
I mean any GN tree is self contained and totally linear, no parallel things, no multiple outputs, just 1 input, 1 output and everything in a static line inside.
Thatâs not very procedural, or at least it does not feel very procedural, this tends to generate long / big / hard to read trees, very difficult to read.
3.- Ease of use
And this makes GN hard to use for anything more than simple things to the average user, I think I said it already, but you need tons of math nodes or operations to do even simple things, and that with the added complexity of âAttributeâ concept complexity, which is very abstract, the spreadsheet and other things help.
For Blender 3.0, together with much needed new functionalities, like curve support and other things, may be a good idea to target to usability and reach to the average artist, not just the progrmamer-profile artists.
The majority of people here is programming-leaned, including me, personally I deal with a lot of different artists on a daily basis and unless they have some programming background they run away from GN, and from the distance they say âamazing!â, but they have no clue on how to deal with several things, this is something that may happen for very complex things, but even in the big H average artists are able to do complex things using just logic and basic knowledge of types and nodes, no need for deep math knowledge or similar things.
Blender 3.0 is a big major milestone, and for sure it will attract more users and more people will enjoy it, thatâs why I think this is a concern.
So I would like to propose this: Blender 3.0 - Target average artists usability
22 Likes
@1 Select the Group Node, bring up the N Panel In the Group Tab you can change the Input names.
1 Like
Thank you so much! Iâm pretty new to this, and there are so many different places to look for settings that Iâm not familiar with yet, so this was helpful! Maybe a right-click (secondary click) context menu option, or being able to double-click and change names like other renaming would be a good addition to the interface?
1 Like
Your welcome. For sure clicking and changing names would be nice but I donât think thatâs possible with the current toolkit.
Its similar UX to the other Editors so its consistent and most are familiar with it.
Pablo was talking bout looking at it to better expose the Tabs when using a lot of Plugins though, maybe something will come out of it.
To reiterate on what @JuanGea said in his last post, Geometry nodes did come a long way, but itâs not there yet (I know itâs still in development, I just want to express what Iâm looking for, maybe others share the same wish)
What people are doing right now with GN is amazing, but they only represent a small portion of blender users (those who know enough math to decide âwhyâ, âwhenâ and âwhereâ to plug this âspecificâ math node to get a portion of a giant puzzle piece working as âexpectedâ)
The other 90% of blender âartistsâ who can only think simple logic, are either smacking their heads on the keyboard trying to figure out how to do some basic stuff, or they are simply ignoring GN altogether and are using âvanillaâ ways of doing things.
For GN to get widespread adoption, it needs (in my opinion) high lvl nodes similar to the âprincipled BSDFâ, nodes that do all the math for you and you only have to worry about moving sliders, pointing at things and picking from drop-down lists)
Want to scatter things ? Add a âscatter nodeâ with everything built into it, Done.
example:
7 Likes
Right, this has basically been the plan all along. The nodes weâve already added are âbuilding blockâ nodes, and the idea is to add builtin node groups to address the higher level ease of use issues. At this point itâs a little too easy to just keep moving on because âthe use cases are possibleâ, but weâre still addressing usability issues like this: attribute search, attribute processor (next), spreadsheet node pinning, etc.
Honestly, I think the most complicated thing design-wise about your proposal is figuring out how enum sockets should work in a node tree.
12 Likes
I vote enum types be bounds checked integers with unique identifiers for type checking. The identifiers would be constant integers with reserved ranges for enums global to blender (built-in) or local reference counted as io sockets inside a node group (custom). When choosing a value via the UI the integer would map to the enum value, when accessing I would make itâs enum value read only outside switches. Enums should be strictly checked and there really isnât a reason to do math on them, only conditionals. I know there is a lot more to it in the backend but this would be my approach. I know string attribute keys are another option but they feel a bit too heavy and are not good for localization.
I still thinking that the easy way could be to allow that groups mix with rest of categories.
1 Like
Exactly, the Geometry Nodes are already quite flexible, but the workflow speed is currently so poor the vast majority of things is just not worth doing in them. The amount of time it takes just isnât anywhere near acceptable for production scenarios. But I hope and expect that to change. That there will be finally nodes we can actually use in those blue node inputs, and chain them together like in the shader editor, instead of having to make linear chains of attribute operators with manually typing attribute names into them.
2 Likes
As my bugreport was close with a ânotabugâ comment (*) I repeat my worries here once more.
When the instanced geometry gets realized it loses all material info. I understand from a technical point of view why this happens. But from a purely user point of view itâs sometimes quite surprising and sortof hard to predict when this will happen.
Like I also wrote in the (closed) bugreport, I have been busy modelling plants using GN (which is extremely nice, I canât really imagine doing it any other way anymore!). For example I used a GN nodetree to generate twigs with leaves, and then another GN nodetree to generate a tree (trunk) and instance the leaves on the tree.
Then in the scene I distribute the trees on the landscape, and Iâd like to add some random deformation to each tree. But this doesnât work, because it causes all leaves to loose their material.
Is there somewhere I can read the plans for how the material handling is supposed to work in the future? Or is it still a subject that needs thinking over?
To me the obvious solution should be to do what the âJoinâ operator does, and merge all attributes into the current object. Or maybe at least make it an option.
I for now did it âmanuallyâ by filling the material_index attribute with 1 for my leaves and adding the leaves material in slot 1. But this only works as long as the leaf objects use only a single material and it gets hairy extremely quickly once you try to do it multiple levels deep.
Iâll quit flogging a dead horse after this post I promise. 
(*) maybe rightly so, itâs not really a bug. but imho it is something which should be worked out.
Yes, this is not a bug. This is something much more serious than just a bug, since it just can not be worked around in any reasonable way. There is absolutely no reason making instances real geometry should not transfer original material assignments and texture mapping to that real geometry. And finding a reason is really just finding an excuse.
I think itâs just not done yet⌠ânot a bugâ can also be âlimitation of current designâ which doesnât mean nobody cares
2 Likes
That seems overly pessimistic to me. Even just doing what the Join operator does would be fine,IMHO, and Iâd think that wouldnât be very complicated to doâŚ
Yes exactly. Even âjust doing Xâ would be great, but currently not even that is possible. Yes, I know geometry nodes are not done yet, itâs just that itâs not uncommon to see âlimitations of current designâ being put in the backlog sometimes even for years.
Geo Nodes is not even Alpha Software right now its very early in development , the âdesignâ is being fleshed out, low level nodes are being designed and implemented and usability is being addressed ( Spreadsheet , Profiler etc. )
With the Attribute Processor and portals coming up I do feel things will get more artist friendly. I would wait for higher level Nodes to be implemented.
Specifically regarding the Instancing issue. I feel its trivial for the devs to fix it, its just not priority right now it is Geometry Nodes afterall ( It could already be fixed though https://developer.blender.org/D11125 )
1 Like
Maybe Iâm still too new in Blender to fully judge on it, just a thought on the usability of GN to average users and artists, is this node based approach not a very particular style that some get a hang of it and others wonât, I donât think I will ever be a master in GN, still great to have for certain tasks thou, but for more advanced stuff Iâd probably lost if there wouldnât be a tutorial for it.
Modeling and other tasks are easier to advance in by having the basic knowledge of topology and the available tools but with GN someone needs to think differently and it is not so visually and obvious what youâre doing with a node, itâs setting and itâs order in the node tree.
Iâve no clue how Houdiniâs approach is in setting up things in it compared to the early steps with Blender into this approach of creating 3d content, I could imagine quite a few artistâs coming from other 3D applications gave it a try once and gave it up after a while not getting on with it as theyâd liked to.
Well, it might be wrong from my side but thatâs how I see it at the moment, of course it would be great if it can be made easier accessible for everybody not only for math and programming minds.
Software usability and design are of course an art of itâs own and itâs not always easy to come up with the right idea, the better it is designed the less often you should need to look up a documentation or a tutorial on it to achieve what youâd like to do.
I read through the task but I donât quite understand it. Does that mean instancing will be faster?
From what I can gather its a restructure of the instances component which should make it more future proof in terms of the DATA it can more around as well as providing some performance improvements.
The last bit is a little unclear to me but it sounds like adding support for other Object types like curves metaballs and Geo Nodes mesh primitives could be on the cards soon.
1 Like