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.
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.
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
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.
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.
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:
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.
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.
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.
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).
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?
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