Geometry Nodes Gizmos Feedback

We made some progress on the gizmo patch. Feel free to test it again. Builds can be downloaded here.

The way things work overall is still the same, but there are some changes:

  • There is an initial Transform Gizmo node. This also supports local/global orientation in the viewport if set up correctly.
  • Node links with an active gizmo have a back-link instead of having the gizmo icon on all intermediate nodes.
  • The Dial Gizmo node now has a radius control.
25 Likes

Did a simple test, seems to be working great!

One thing I noticed (may be a known issue), is it doesnā€™t seem to work with auto keying. If I add a keyframe to a value controlled by a gizmo and then change the value manually auto keying works, but changing it by moving the gizmo doesnā€™t add/update the keyframe.

12 Likes

Playing with Gizmos and SDF ā€¦

The node tree is convoluted. Instead of Group Inputs, I plugged constants to the gizmos. Clicking on the constants gives me the controls for the gizmos.

4 Likes

Just used these for the first time. Sorry, realise Iā€™m coming to this thread a bit late! I love the power of having visual inputs to the Geometry Nodes setup, but Iā€™m also struggling with the idea of having bidirectional connections in the node graph. Iā€™m a pretty heavy Geometry Nodes/Shader Nodes user, and it confused the hell outta meā€¦ IMHO it potentially makes the system a lot more confusing to use and harder to learn.

As the original proposal says ā€œWith gizmos, there is a fundamental two-way dependencyā€, which is of course different from all existing nodes, so I wonder if a different way of interacting with them would be more easily understandable.

A few people have touched on this already, but perhaps it makes sense to treat gizmos more like drivers than like nodes. You can right-click any value and ā€œadd driverā€, perhaps it would be more intuitive if you could you also ā€œadd gizmoā€ in the same way?

Not sure how you would control the gizmo parameters - you could go continue with the Drivers route and have a some kind of Gizmo Editor I guess, but a more node-y option might be to add the gizmo parameters to the node that contains the value, in a dropdown panel directly under the value itself, rather than creating a standalone node (see very basic mockup).

Sorry, I know Iā€™m coming to this conversation pretty late and I appreciate thereā€™s already a lot of work been done in the node network direction, just my two cents as user :slight_smile:

7 Likes

I find the ā€œTransformā€ Output socket confusing as it
a- doesnā€™t output Geometry,
b- abuses the join geometry node (no way to guess this without reading a doc),
c- ā€œfeelsā€ more like an input than an output in functionality - I think some of this is covered better in other posts.

Some Ideas/Mockups:


1- Change it to an input and just plug the desired ā€œlinkedā€ Geometry into it - is slightly more intuitive in that it doesnā€™t abuse the Join Geometry node, yet still indicates that it is an association with that particular geometry, more succinct in that it doesnā€™t require an extra node, and doesnā€™t create a noodle that looks like a Geometry Noodle but isnā€™t, we could change the name to"Linked Geometry" or ā€œTarget Transformā€ or some other phrase that gives more information

2- Keep it as an output, but change the type to a (new?) color/type perhaps simply ā€œgizmoā€ and create a new ā€œAssociate Gizmoā€ Node that takes a geometry socket and a gizmo socket.

3- Since we can now name Geometries use name association

4 Likes

Starting a new post building on the previous:

  • it might be nice to distinguish the ā€œValueā€ Input that the Gizmo controls from the Position/Rotation (in this case) inputs that update the gizmo itself. One possibility is renaming the inputs, another would be adding a label / header, or perhaps (ab?)using panels to provide this:


    Note: Itā€™s possibly better to move the Linked Geometry into this Update Gizmo Panel, since it also affects Gizmo updating?

  • Taking Option ā€œ2ā€ from the above post a bit further - if there is a separate Gizmo Noodle, we could perhaps move all the ā€œupdatingā€ inputs - position, rotation or linked geometries, into a separate node that could be used for any gizmo type:

5 Likes

Iā€™ve pointed most of these issue with bidirectional design back when this patch was more experimental. I am really worried that now 4.3 is in the beta, it will either stay in its unintuitive form till eternity, or there will be another big backwards compatibility break like there was with attribute based geometry nodes.

IMO thereā€™s just about enough time to retract the gizmos and put them into experimental flag until some better, non-confusing design is figured out.

5 Likes

Iā€™m not positive itā€™s at all confusing if you think of it the same as another geometry output from the nodetree.

Even with my #108744 - WIP: Geometry Nodes: A Modeling Approach of Gizmo - blender - Blender Projects itā€™s only the way to make things workable with nodes concept is to back propagate relations. Otherwise youā€™ll deal with cyclic relations in just some other way. You just can not combine node tree and its meta controlling without introducing other node tree or creating parallel node graph in the same tree. So back propagation is actually the solution, that can be reused for other kinds of the node tree.

1 Like

I just tried the Gizmos and I think I got the hang of it relatively quickly.

However, I am struggling with the Transform Gizmo. Here is an image of my node setup and from my understanding the gizmo should be rotated just like the instance of the cube is rotated, that is in this cas 45 degrees on the z-axis.

The Gizmo does move when moving it but the rotation is not reflected in the gizmo.

What is the problem here? Is this a bug?

In the 3D viewport, set the space from Global to Local. I donā€™t know why this works the way it does. Seems like itā€™s backwards almost (Global vs. Local for rotation).

2 Likes

Hello, Iā€™m writing this post because I had a question while using Blender 4.3 beta. After reading the threads, I donā€™t see any discussion about using gizmos in edit mode. However, I think gizmos are more necessary in tools rather than modifiers, because modifier values can be adjusted anytime in the modifier tab, but currently geometry node tools only allow strange and limited control using the mouse position node. Will gizmos be available for tools in the future? Or do you have different thoughts on this?

5 Likes

Hello. I noticed that if we place a gizmo in a node group, and then after leaving that group, the gizmo is no longer visible in the 3d viewport.
Is this something that can be improved, or do I just need to remember to always have the gizmos in the main tree?
Thx

This button when toggled leaves the gizmo visible even when the nodes are not active:

2 Likes