Edit > Adjust Last Operation (F9).
Understanding Operation (keyboard shortcuts and menu items) vs the Active Tools is as essential as understanding Fake Users.
Please stick with the terminology that the community already struggled to learn and understand and puts effort into teaching new users, especially since you’re not going to remove usage of “operator” and operation in all the long pre-existing places.
Throwing another idea, I work with a lot of scripts that iterate in timeline and only do operations on frames that are keyframed. I can replicate operators in tools already, but if there was a way to check “Is Keyframed” in simulations for object transforms I could do some great work with that.
The ability to use instancing within the geometry nodes Tools would be a total game changer, the ability to use the “Selection” node as the selection so you only instance on those points would bring so much potential to workflows, even if it was limited to the instances being primitives/etc it would be a great start.
Agreed. We currently have no way to store instances as original object data though, so I’m not sure how this would work. Potentially it would work in combination with a modifier asset that actually does the instancing, and the node tools would control attributes fed into that modifier.
To that end, linking modifier assets and node tool assets may be one of the important next steps of the project.
Yeah. The other option I imagine would be to somehow allow the selection node (or something similar to the way you can mark edges sharp) to work in the modifier version. That would be fantastic.
I wanted to make a circle tool (inset active face(s), subdivide them and arrange their verticles in a perfect circle) so that I don’t have to use complex addons just for this simple operation:
I got very quickly stuck when I realized that GN version of the Subdivide Mesh can’t take selection, but subdivides entire mesh instead. This is a common issue with many GN nodes. For example Subdivide Operator can easily subdivide only selection:
Now that we have node tools, which are usually expected to work just on the active selection, having at least a few more nodes accept selection would go a very long way.
I mean, if you have something that can only affect entire mesh, then it loses a point of it being a tool, since you gain almost nothing by doing it a destructive way, compared to procedural way using a modifier.
Also, now that we have repeat zones, if even just the Subdivide Mesh node alone got a selection input, it would open a whole new world of adaptive subdivisions solutions for example driven by distance from camera and so on. (You could use repeat zone to recursively shrink selection distance from some point (camera, or empty) and add one more subdivision to the selected faces. That way you could prepare geometry for distance adaptive displacement for example. Combined with merge by distance node, it would even allow for a rudimentary decimate/remesh node group)
Not sure this would work as expected.
Corner verts will merge, but it will leave holes on areas where subdivision levels of neighbouring faces do not match.
But it is an interesting idea to split the mesh to create different subdivision levels.
I guess … we would need to subdivide the edge-ring around the lower subdivision area to match the subdivision level of the neighbor areas. So there would not be holes after merge-by-distance.
Yes it breaks the topology. I guess some retopology algorithm is required for that.
Yes, breaking the topology is still a dealbreaker. There will be gaps in the geometry when displaced.
It’s still not ideal, but you can fix that with a merge by distance node to combine the duplicated vertices
No, I am pretty sure that won’t work. You will still have gaps/open edges where the vertices don’t have closeby to merge with.
So all the yellow ones end up still double, open edges.
Yea, subdividing locally should probably create ngons at the borders
Ah my bad, I didn’t think about that carefully enough 
That’s really cool. A bit sad that it’s 1.5 versions away (at least) 
I am really enjoying Sdf Nodes, is there a way to insert them into sculpt mode like brushes in the future? For now gizmos of translate, rotate and scale will be wonderful. I am looking forward to what happens in the sdf front.
A bug in sculpt mode that doesn’t happen in edit mode is when I try to use original object in node set up, things go crazy , object dublicates itself or doesn’T respond as expected. You can test the file below.
Some setups I was playing with: SDF Boolean Tools and Blur for edit mode (saw this on twitter and developed it a bit)
Here’s a thought:
Since we have these buttons
Is there a necessity to also have this switch?
The difference this switch makes is that it adds the object type and mode buttons on the header. It also allows for the few tool-specific nodes to appear in the add menu, etc. These changes are pretty small.
Why not just make these changes take place when the “Tool” checkbox is checked instead?
And since the same node group can be set to only work as a modifier, but not a tool, and visa versa, the search (on the header) separation of the two makes no sense.
Now, instead of typing the warning “Node must run as tool” on the modifier, when a tool node is used, and making the modifier not work at all, the tool-specific nodes could output a default value. For example:
The “Selection” node, would just output a “Yes” (Everything) when used in a modifier.
The “3D cursor” node could just output “0,0,0”… Etc.
With these changes, the node group may not give expected results, but it would work without error, for the modifier. There should still be a soft warning on the node itself, that this node only works for tools, not modifiers. (“i” icon, not “!” icon".)
I got around to testing tools for actual practical purpose. I have created an add-on that converts face sets to other attributes for different purposes. Julien showed interest in it and created design task, where it was proposed to create those operators with node tools. So I wanted to see what was doable currently out of those operators.
I will exclude Convert to Attribute from this testing, since it’s straightforward and obviously possible.
For that, I needed to be able to select faces in each individual face sets, which I found quite hard to do. I did it, but index assigned to each face set seems very random. When using stylized female model from base meshes bundle, and store face sets as attribute, index goes from 6 to 46, to 44, to 45, to 26. I can’t figure out pattern, but when selecting faces with that index, it doesn’t correctly select every face in face set. Only partially. I’m not native to Geometry Nodes, so I am probably doing something wrong, tell me if that’s so.
Ideally index should start from 0 and end at number of face sets(-1). That is whay my python code does at the moment. That makes using it in geonodes extremally easy.
As for assigning materials, I was pleasantly surprised that it worked. But when you assign material on the object that has no material slots, it creates empty material slot, and actual material is put in slot 2. I don’t know if you’d consider this a bug, but it’s there. In rest of the cases it works as expected.
As for assigning materials for each face set, I think it will be possible with new For Each zone, once it lands. Or am I misunderstanding what that zone is for?
And it works! I was able to get same exact result as python operator!
But the obvious limitation is that it works for UV unwrapping, but not for simply creating Seams. That is a big limitation because seams are important for some add-ons, most importantly Quad Remesher. Obviously we can save attribute, select and mark as seams, or addons can change data type they use, but still. I know I don’t need to say this and it’s obvious to geonode developers, but seams as generic attributes would be very good.
I’m not gonna try to recreate this now, because of issue I had in materials, without correct index I can’t work with that. But another obvious limitation is that I can’t directly create Vertex Groups from geonodes without doing manual steps myself.
That limitation isn’t important if goal is to simply be able to select face sets, there can be workarounds. But I keep thinking and if node tools specifically allowed creation of vertex groups it could result in some amazing results. Design I had in mind would be to assign faces to a group and assign weight to that group as float. What that would give us is ability to procedurally create field and basically assign that as vertex group weights. Easiest example would be using Easing nodes to control fall-off for weights towards edges. That can be very powerful for quick and dirty rigging.
Here is blend file if anyone wants to experiement more with the concept.
If we’ll solve incorrect index issue I’d love to create assets for Face Sets as discussed in design task.
