Geometry nodes tools will be part of Blender 4.0, now accessible as part of the daily builds. There’s more info in the manual, and more info about long term plans in the overview task.
Similar to the simulation nodes thread, this thread is meant as a place to share creations, feedback, questions, and discoveries about the node tools features.
It’s easy to imagine how node tools could be expanded. I’m curious which features people would find most useful, but I’ll preempt some of that with a short list of things that are already vaguely planned-- limitations we’re already aware of (there’s more in the overview task):
Shape Key support. Shape Keys procedurally is a dream of mine in GN in general, but I think you’ll be more open to allowing Active Shape Key node similar to face sets. I already have add-on for that which I could swap for shareable assets, and do many more, such as:
Simple operators such as duplicate and merge
Splitting shape keys into clusters based on some groups, maybe textures, or edit mode selection to have ‘Split Shape Keys’ operator
Create ‘Shape Key Pose Library’, store group of shape key values as attribute and reset values from those attributes, like store face sets - restore face sets.
There are no questions about the feature itself. Except for one thing… A way to integrate operators into the UI. The existing system based on the catalog hierarchy, in my opinion, is somehow not very. After all, catalogs have a completely different purpose, namely for grouping assets. Of course, in an attempt to build a menu, you end up with an ordered hierarchy, but at least this is a rather cumbersome way. Perhaps, instead of the catalog hierarchy, it was worth introducing a property like “UI Path”. Each asset will have it, and it has the format "menu/submenu/sub-submenu/etc....". For example, it would be much easier for studios to make changes to the hierarchy. And also, if desired, it would be possible to add the ability to embed an asset in several menus (putting “;” between paths), it is impossible to do this with a hierarchy. But unfortunately I don’t actively use the asset system, it’s worth asking the opinion of people who participated in large productions
With my first tool experiment I tried to recreate the ‘Pick Shortest Paths’ function. I was able to approximate it, but it required a workaround due to the lack of an Active Selection input. (As seen in the image)
The workaround was to put the 3D Cursor where I wanted then select by the distance to it.
Setting the selection to be an edge is also not available currently.
Tools seem to have a lot of potential, and the current limitation seems to be the amount of input data available.
(Sidenote: you can’t directly search for the 3D Cursor input because it has a number first. It instead automatically selects the 3rd item in the menu)
Shape keys and geometry nodes definitely have an interesting future, but given the vague goal of converting them to attributes, I would be wary about integrating them further in the meantime unfortunately.
We have discussed this a few times in module meetings too. Indeed, some day it may be obvious that we need more flexibility. But for now it was preferred to keep things as simple as possible and avoid adding multiple ways to configure things.
This method of organization does push asset authors to use more generic asset catalog names. For example, instead of “Hans’ Node Toolbox > My Mesh Tools” > Randomize" it’s just “Mesh > Randomize”. There’s value in that too, in my opinion.
Very nice!
Good point. A node with a boolean field output may be misleading, but maybe that would work. It’s tricky that the active element could be a vertex, edge, or face. We’re definitely held back by not exposing the selection modes here too. I wonder if a “Selection Mode” node with three boolean outputs would make sense.
Hmm, I think that’s an oversight! I’ll see about fixing that.
Is “Tools” really the right name for this?
Shouldn’t these be called “Actions” or “Operators”?
A tool, i think, is something you perform multiple actions with. For example, the active tools, it’s a tool you take from the palette, and continuously perform actions by left clicking.
In other words:
A Screwdriver is a Tool.
To Screw in a screw is an Action you perform with a screwdriver.
Yeah it’s confusing me too. This goes against what is tool and what is operator in Blender, which is very strictly defined. I’m assuming they’re planning to somehow combine making actual tools within this system and are preparing for that. Otherwise it’s not making sense and makes it harder to explain to people what they are.
I guess, that eventually there will be active tools, that can perform ACTIONS defined by a Geometry nodes node group, for example.
So yeah, calling these actions “Tools” makes no sense to me.
To be honest, I don’t know what a node tool is ( a node group asset ? a modifier ?) every time it is mentioned somewhere it comes with a wall of text talking about everything and anything except what is it, no visual examples.
Thankfully the few examples on this feedback thread helped me understand a little bit (even though I still don’t know their purpose, since to me they look like a node group asset).
The concept is great. Super useful. I tested out a few random things. Anything you can make in geonodes seems to work as an operator, apart from anything relating to instances, since they cannot be accessed in edit mode (right now it silently fails, but it should probably inform the user).
Yes, they’re supposed to be operators. Tools are a different thing. I would stick with the naming already established in Blender
Yes, not only that, but if we admitted that they are just operators, not full fledged tools, then it would open possibility of having actual GN Tools in the future. Right now, what people complain about is how the GN Operators are exposed in the UI. If we also had GN Tools, then each GN Tool could just pop up as another icon on the left toolbar.
But of course GN Tool implementation would be much more complex than operator. It would require additional UI to filter what’s a tool toolbar property vs what’s redo operation property. It would require something to select an icon for the tool, it would require support for gizmos and possibly also keymap definitions. It’s getting very complex at that point.
Still though, having current GN Operators actually called operators would at least be future-proofing for the possibility of GN Tools existing.
To explain it in simplest terms: They are user-made custom actions.
For example, when in edit mode, you can Inset, bevel, extrude, and so on. These are operators/actions native in blender. If there’s an action blender can not do natively, the users can build one themselves in geometry nodes and then use it when modeling.
For example, blender cannot do Offset or Outset, It is possible to build such actions using geometry nodes.
These actions can also be shared as add-ons in the community.
About “Node Tools” vs. “Node Operators,” the idea was the other way around-- that choosing the more general term “tool” would allow extending the behavior to active tools. We also thought that most Blender users (probably less so users on this forum) wouldn’t make an important distinction between “operator” and “tool” and the latter is a more accessible word.
Actions are already a thing, in the animation section of Blender. We need to not call two entirely unrelated, differently things “actions”.
Similarly with "Operators’ - that’s already a thing. When someone is solving a problem and told “you need to create an operator” - that sentence has a meaning. We shouldn’t introduce a conflict in terms, so that people now must decide if we mean "write some python code’ instead of “go make some nodes”.
I sort of feel the same way - i read the new page in the manual, which is … a nice clinical definition, but doesn’t really show an example of “here’s what this does, here’s why it’s great, and here’s why you might want to use it.”
Its a bit like reading “The paint tool allows the user to manipulate specific pixel color values (0-1 internal range) using a mouse-driven indicator over a variable area.” Technically, exactly what it does. But as is often said in a movie: “Can we try that again in english?”
Alright, i agree about not calling it an “Action” then, as it would be confused with animation actions.
But “Operator”?
Why does it matter, whether the operator is written in Python, or nodes if the result serves the same purpose? Why would it matter what’s under the hood, if at the surface they are both operators? They can be distinguished by saying, like “GN Operator” (Made with nodes) or “Operator” (Made with Python).
Because the context in conversation is completely different, as is the procedure of creating them and using them. Part of good naming conventions - ie, using the raw tools that language itself provides - includes using terms that don’t always require a context to understand the definition.
“Under the hood”, so to speak - sure, it’s an operator with a twist. But that doesn’t mean we always should apply “code speak” at the top level.
Blender has several examples in it’s native terminology that already create confusion right out of the box, and I think avoiding this as the application evolves is easily done, and should be.
That’s what these are, operators. There’s just a new way to create them now.
Ok. Well, there’s an established terminology, and a real, practical difference between those two things. Now if the plan is to blur the line between them and say, populate the active tool list with geonodes-made tools and operators, and allow modal operators to be made, possibly with gizmos and all that jazz -perhaps that difference indeed becomes less meaningful.
Perhaps I’m misunderstanding this feature, then. Which is entirely possible, is I have not seen very many concrete examples of what this actually does (noted above).
Even with the extrude bevel example it’s not obvious to me how this is any different than a standard geometry node application. I’m not saying that it is not different, simply that it’s unclear what the difference is.
Does it do everything that python operators do… Such as create toggle buttons with specific app-level functions in the header, npanels, etc? If yes, that’s quite exciting.
Right, it’s entirely possible to currently do this when a geo node. So gets to “how it it different” … this feature is a full-blown tool that isn’t “locked” as a modifier? Nice.
(Which to me, sounds like it should be called a Tool.)
