A potential problem with using colored properties is that the properties can have keyframes AND have a gizmo attached. Any idea for how could be represented?
Hmm good point. Any way to address that issue will overcomplicate things for sure. So either it can be without color, or it can have color until it’s keyframed or driven. I like second choice better, it still gives more information out of the two, and I think if somebody keyframed gizmo positions they already know which properties they’re working with and don’t need that identifier anymore anyway.
And that idea took me down another path and tried attaching driver to the value that is being controlled by gizmo. And as was probably expected gizmo doesn’t work anymore, it can’t change anything, but is still there and its position is updated.
I think there needs to be some UX there too, maybe make gizmo disappear, and turn gizmo icon in modifier into info/error icon that popup on the nodes when you plug in wrong type of geometry, so that it tells you gizmo is not functional anymore.
I am still trying to figure out the technical limitation that doesn’t allow value to be output, but has to be input instead. I mean gizmos are essentially just some objects in 3D space with location and direction.
Naively, the abstract way I would expect them to work is that their inputs would be initial position and initial direction vectors, and their outputs would be current position and current direction vectors. So user could then take these 4 values and use them to drive anything they want. For example use distance from initial location to current location to drive some value, or use dot product from initial direction to current direction to drive something.
All these examples show very simple scenario, but I am just worried about quite overcomplicated node networks if there are many more nodes between the gizmo value input and the value constant.
So basically the input values of the gizmo would be where it’s initially supposed to be positioned, and output values would be where the gizmo currently is (after user has transformed it in the viewport). That would feel more intuitive than the current bidirectional feedback loop setup user is required to make.
So that was the reason for my original question - if the reason of the gizmo output being on the input side was aesthetics/convenience or some technical roadblock that wasn’t solvable any other way.
That icon placement and appearance just looks… sort of hacky and arbitrary.
Perhaps something that looks more directional, and like everything else.
4 Likes
It is possible to have two gizmos on a single value.
Is there a use of multiple gizmos on one value?
They mentioned an example use case in the proposal
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.
Thank you.
I think I get the idea now. In a more complex modifier, being able to tweak the same value from different locations (instead of sniping for a gizmo somewhere).
The problem with this node-tree is that the Gizmo value ignores the math node, and jumps directly to affect the output of the “Value” node instead, therefore connecting it this way makes little sense.
Maybe a good idea is to separate the Gizmo node into two: “Gizmo value” and “Gizmo Display/Shape”.
These two nodes would need either a name or an index number to be linked together.
Perhaps easier with indexes.
So… the “Gizmo value” node would have two inputs (“Index” (integer) and “Type” (Float, integer, etc) and one output: The “Value” output would simply be based on the “Type”.
The “Gizmo display” node would look exactly like the Gizmo node is now, except that it wouldn’t have the “Value” bidirectional input/output socket, and would need an index integer value input.
If “Gizmo value” and “Gizmo Display” have the same index nr, they are linked. Adjusting the displayed gizmo adjusts the value and visa versa.
The only problem that remains is that there is no way to connect a gizmo to the primary node-group input with a line.
That can be solved, if there is a new setting in the “N” panel, for node-group inputs, which is simply called “Gizmo index”. The user would just write in the gizmo index number, and the input would get linked to it.
If a node group input is linked to a Gizmo in this way, there is no need to use the “Gizmo value” node anymore.
NOTE: The Gizmo indexes would be Groupnode dependent. A Gizmo with an index of “1” is not the same Gizmo, with the same index, outside of that nodegroup.
This is quite more complicated than the current design, but this makes more sense to me.
Also, this design would allow two gizmos (or more) on the same value, as @LeonardSiebeneicher requested. To achieve that, the two “Gizmo Display” nodes would just need the same index number.
The best solution i could think for that is having a new button icon on the header of the modifier, along with these:
The new icon would have three stages: “Always display gizmos”, “Display only when modifier is active” and “Don’t display gizmos”.
Gizmos are a visual way of editing the parameters of geometry nodes and modifiers. Similar to how transform gizmos are a visual way of editing the location/rotation/scale of an object. Not like an additional object that is driving the object transform.
You want to be able to inspect, manually edit and keyframe the resulting parameters on the modifier.
1 Like
If it was done the initial position/direction in and current position/direction out, then I guess you could always use vector math to add offsets using let’s say keyframed vector inputs. You could either add the keyframed value before it goes into initial position, to animate the gizmo before it gets transformed by the user, or you could add it to the current position, to animate it after it was transformed by user.
I still just can’t figure out what technically necessitates the output being on the input side and requiring reverse direction flow.
EDIT: Visual example:
This:
VS something like this:
And I guess the node would eventually also take single value bool to toggle whether gizmo is visible/active.
2 Likes
One thing to keep in mind is that we eventually want to extend the system so that we can show a gizmo e.g. for every vertex in a mesh. Imagine for example a forest generator node tree that places a tree at every vertex and there is an attribute on the vertex that affects the size of the tree. That implies that we want to be able to edit attribute values with gizmos directly.
4 Likes
How would that be done with the currently proposed gizmo system?
In my mind, for multiple gizmos for use case in your example, I would imagine something like gizmo fields:
Something that would draw a gizmo for each element in the field.
I guess my general point/idea is that I perceive the gizmo node as a very simple container for delta between initial parameters and current parameters, and what generates that delta are user’s gizmo interactions in the viewport.
This would solve also the current issue of gizmo having this weird transform geometry type output, which has to be joined. In my case, I would assume you can simply transform the initial position if you want it to stick to some transformed space.
(EDIT: I removed the current position and direction outputs as I’d assume the circle gizmo is just for setting of radius, and can’t be moved/rotated.)
2 Likes
Well, essentially it can just work already without any extra gizmo specific nodes. It would require the work-in-progress for-each zone though to generate the individual trees for every vertex. The point here is that I can just define the gizmos in the tree generator node group and depending on how the node group is used I get the gizmos just ones or per vertex of whatever I want.
An alternative approach that we’ll likely explore as well is to have attribute variants of the gizmo nodes like in the image below. That would be more efficient for some simple attribute manipulation and when the for-each zone is not required anyway.
It would not solve the same problem. Sure you can always pass the transformed position to the gizmo node directly, that can be done in the current proposal as well, but that is not the point. The goal is to be able to create assets like the tree generator where the gizmo stays “attached” to the tree in the viewport even if the tree is moved somewhere else after it has been generated. The node group that generates the tree shouldn’t have to care about what is done with the resulting tree afterwards.
3 Likes
This makes perfect sense workflow wise, but would this be in any way incompatible with the previous example of single-value gizmo without reverse direction flow I proposed?
If this single value gizmo node adds one gizmo to the viewport, then if this whole thing is node-grouped, and put into For-Each zone, it would achieve the same effect but we would still not need to introduce the reverse flow concept?
Say you wanted to create a gizmo for the Angle in the Simple Deform modifier. I would expect to be able to edit the parameter itself, rather than some Delta Angle parameter separate from it. And that Delta Angle value would still need to bubble up to the modifier somehow and become a parameter there, since it can be different for every object that uses the same node group.
If you can’t edit the parameter directly, it just seems convoluted to me. Imagine if the same were true for object location or spot light angle gizmos. Surely users just want to edit the actual parameter, not some delta parameter?
1 Like
Yeah, I guess that makes sense. My intuition still tells me the there must be some more user friendly way, but I will have to take some time to think about it. It’s true that if user set angle on the modifier input, which was then modified by the gizmo, in my solution, that new, gizmo-modified angle would not propagate back to the modifier input, so the angle would not match, which wouldn’t make any sense.
2 Likes
My little feedback would be to please put Gizmo category in Add menu in Utilities, or somewhere else. With asset libraries that menu is getting too tall and unmanagable, I have just 5 categories and it’s already too tall, no need to make it taller for couple of nodes
2 Likes
The color spacing on the reverse node line looks a bit like a display error, especially when it’s slightly not straight; perhaps if the gaps were smaller this would improve.
1 Like
