Gizmos for Geometry Nodes [Proposal]

[jacqueslucke]

This document is a variation of what was presented on the blog.

Viewport gizmos play an important role in making common features in Blender accessible without having to learn shortcuts. Similarly, gizmos for procedural assets can make the asset usable directly in the 3D viewport, without having to dive into potentially long parameter lists.

For example, in the mockup below, the height, twist and number of spots of a procedural vase can be controlled with gizmos.

The goal of this task is to describe how gizmos can be integrated with geometry nodes in a way that is well defined and flexible enough to support the following features:

• Support various kinds of gizmos (translation, rotation, etc.).
  • Technically, we could support custom gizmos where the gizmo shape is generated in geometry nodes, but we intentionally don’t want to allow this for now, because we would rather have a small set of of well known gizmos that have a consistent look and feel.
• Support using a gizmo in a node group without the intention of turning it into an asset.
• Support exposing an arbitrary number of gizmos from a node group.
• Support building more complex custom gizmos as node groups by combining existing gizmos.

Gizmo Nodes

The proposal is to add separate nodes for the different kinds of built-in gizmos.

There are two main challenges to solve:

• Where is the actual gizmo value stored?
• How to deal with the dependency loop that the gizmo position depends on gizmo value, but the gizmo value also depends on the gizmo position?

The proposed solution is to make the Value input of the gizmo nodes special. To detect where the gizmo value is stored, we statically follow links backward from the Value socket until there is a value that can be changed destructively.

In the simplest setup, there is an input node connected to the gizmo value. In this case, changing changing the gizmo in the viewport changes the value in the input node. Only reroutes are allowed on the path from the input to the gizmo node.

This approach allows the same input node to be used with multiple gizmo nodes. I could see this being useful in more complex setups like a castle generator where there are multiple gizmos in different places that control the same wall thickness.

The other inputs in the gizmo node can depend on the value and determine where the gizmo will be drawn in the viewport.

Since there is no output on the gizmo node it is more obvious that this is just a node that affects the UI, similar to the viewer node.

The gizmo value can also be linked to a group input. This exposes the gizmo to the calling node group or modifier. So in the image below, the gizmo in the viewport controls the Value input of the group node on the right. To further expose the gizmo up to the parent node group, one just has to link the value to a group input again.

[modmoderVAAAA]

I described the result of my reflection on this in Pass editing data through geometry nodes.
The main problem with passing the Ownership of a Value by socket to the top of the stack of nodes in the tree is that the values are positioned depending on the context.

• I broke the link:
  • Where are my values?
  • Are they copied to the node below?
  • Are they still in the node above?
  • What if there are 2 nodes connected to this?
• I am copying the node tree to another object:
  • I want a copy of the values!
  • I don’t want copies of the values!
• I am copying several nodes in a group:
  • … .

The main problem, also, as I see it, is that it still doesn’t solve the problem of it being just a one-pot thing. So if I wanted to rotate the vase, or instantiate it, how would the gizmo handle it?

This means that the gizmo must be a geometry that the user can handle like any other.

This is an early examples of how I see the solution:

Summary

The value is stored as usual. It is easy for the user to change it. Copy, Past, Add, … .
There is a simple, defined interface for operations on these values, and that’s it.

As an extension of the idea of context-sensitive values, it would be easier to create those kind of values first. This would be similar to the preview node. But it would allow you to enter arbitrary values in the random instances of the group in the modifier. I’ve been thinking about it and it looks like a very fragile concept (questions above).

[jacqueslucke]

You bring up so many different topics that it is hard to know what you main point is. I’ll try to answer the important thing:

@modmoderVAAAA

Where are my values?

The values that are controlled by a gizmo can be stored in three different places in this proposal:

1. The value of an input node, e.g. the “Value” node.
2. An input socket of a group node.
3. An input value in the geometry nodes modifier.

There is no new special behavior with respect to copying.

[dfelinto]

Interesting proposal. Indeed the proposal from the workshop had the same issues. I have some comments that apply to both cases:

• The socket should be visibly different (an arrow point left?).
• The property which is “driven” by the Gizmo could also get a special color to match the Gizmo node color.

So, the main different here is that instead of treating the node as a special pass-through, we make it more close to the Viewer node. I think that can work.

[modmoderVAAAA]

In other words, this design implies the task of creating a new socket class. These are sockets that duplicate all previously existing math types (most of them, not just gizmo float).
And at the same time they have a reverse principle of flow (yes, the value goes as before. But the possession of the value reversely rises).
This already sounds like a complicated topic. And it most likely has a bunch of problems (didn’t try to reflect on this much. The simplest example is interaction with all the old nodes and their number of connections to output sockets (what would it mean to be able to do this?)):

1. Default value flow:
   
2. Gizmo value flow:
   
3. Combination? Quantum mathematics?
   

[HooglyBoogly]

It’s a little hard to understand those diagrams. But I think it’s better to think of gizmo nodes in this design as just UI helper nodes that can be attached to values to give control to them in the viewport. Yes, that means the links between the values and the gizmo nodes aren’t real data-flow (so they should probably be drawn differently to make the distinction clear). But I don’t think that makes the design wrong.

[modmoderVAAAA]

@HooglyBoogly

that can be attached to values

Exactly.

The problem is that this function is meant to be implemented as links between nodes.
And here, we either create a new class of nodes, yes this.
Or we say: the result of the math addition node can be connected to 2 other nodes.
If both nodes are gizmo nodes (we invers additional value to ui). Then we attach UI to the gizmo… number 1 or 2?

[MartinZ]

It’s just a random thought, but could there maybe be a single gizmo node that would have options for gizmo functionality type and appearance and it might be awesome to be able to define custom gizmo apparence with an object or geometry input.

[Oxicid]

I really like the addition of gizmo in geonodes, and I hope that in the future they will be added to the usual modifiers (Mirror, Array, Scew, SimpleDeform) so as not to breed empty things on the scene.
And for better control they should probably add a gizmo on/off switch to this row as well.

[Baardaap]

I think the plan is that all modifiers eventually get implemented as (bundled?) GN nodegroup assets.
That way the gizmos will follow along.

[FreeMind]

oh yes, but the label showing only the first two letters is quite ridiculous.
At this point, the label and buttons should become two rows if the properties editor is not wide enough.

[Jason_McSorley]

@jacqueslucke Is there a general design spec yet? I have some ideas/suggestions, but I don’t want to clutter up this thread with a discussion that should occur elsewhere.

Feedback is around:

• updating of the gizmo during adjustment
• customizing gizmo presentation and appearance

PS: Thanks for the work on this. I didn’t know this was in the works when I started searching for something that provides this functionality. It looks great so far and I have been enjoying following along and playing with each new revision.

[Nicolas_Bourgeais]

Yes there is a dedicated post :
https://devtalk.blender.org/t/geometry-nodes-gizmos-feedback