Geometry Nodes Gizmos Feedback

[Hadriscus]

Hi, thanks for working on this !

@jacqueslucke

To fix this, the gizmo nodes have a Transform geometry output. This should be joined into the geometry that is controlled by the gizmo. Now, Blender has enough information two know that the gizmo should be transformed together with the grid. Typically, only people creating node group assets have to care about this. For people who use the assets, these transforms should work automatically.
(…)
Note that this only works within certain limitations, since Blender can not always figure out how changes to the geometry should map to changes in the gizmo transform. If there should still be a gizmo in such complex situations, it is better to just create a new gizmo and to compute its position manually.

I like the idea of letting the actual nodetree transform the gizmo. What are the cases where it doesn’t work? when fields are involved?

@jacqueslucke

These rules could be fine tuned with some user feedback. Manual control over gizmo visibility might also be added at some point.

Let’s see how assets turn out with these gizmos, but I suppose it’s the responsibility of asset creators to not overload a given asset with them. If toggling is necessary at one point, it can be done from the dedicated viewport popover. Are you thinking of a per-gizmo toggle, from the modifier/nodegroup interface?

@jacqueslucke

How do we differentiate “normal” links and links that are used to connect gizmo nodes to the value they control?

@jacqueslucke

Do we have to show which input values have a gizmo and if yes, how?

Nodes probably need to expand the “info” zone where they currently display the number of attributes used and the timings. We could show the gizmos in there as well as any actives caches. If we choose to cram it in there though, the overlay should probably show only on request, a bit like we inspect sockets right now. It would be too busy if we had to show it all the time.

@nickberckley

I wonder why not allow color input for gizmos? Why is color constrained in the first place? Is that performance thing?

I suppose so it always plays nice with the default themes and backgrounds. I think the idea is sound, but the gizmo palette should be largely extended.

@jacqueslucke

That one is pretty much undisputable to me as it would limit the flexibility of the system significantly. It’s very important to me that gizmos are just UI for inputs that can also be modified by other means (e.g. procedurally).

How would you handle conficts between a value that’s both defined procedurally and connected to a gizmo?

@jacqueslucke

Since there is no actual data flow in these new kinds of links, only a very limited set of nodes is allowed to be used with them which will be explained below.

@jacqueslucke

the Math node has special meaning to the gizmo nodes.

I’m not sure I understand why other nodes that manipulate floats aren’t supported by gizmos? shouldn’t they work, as long as they’re not fields? how do you intend to communicate that only some nodes in certain modes work?