One thing that I’m thinking is that I’m willing to give up ability to control number both as node input and gizmo, and only have it controlled by gizmo if that means left-to-right is used and I can simply plug in gizmo output in the value that I want to control. That behavior is worth the trade-off for me.
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).
Fortunately, the kind of gizmo that just acts as an input is kind of a special of the more general design shown here. For example, a position could be created like so (note that I just found a bug that the gizmo positions don’t update if you don’t actually use the position output of the node):
We already talked about the possibility that we ship this and potentially other similar node groups with Blender, and it seems reasonable. Feel free to build other node groups of this kind that could be bundled.
but to simply scale it you need to join it?
The scale is currently not really part of the gizmo definition because it’s view dependent. An additional scale factor could be added at some point if there are clear use cases.
Note that simply adding a scale input in no way removes the importance for the transform output.
I don’t like gizmos at first instances, I know it can be changed by some calculations, but almost every time I would expect it to be in the middle of all instances, similar to how transform gizmos are drawn when you have median position as pivot point.
It does not seem to make a lot of sense to draw these gizmos that apply to a single instance in the median of all instances, because then the gizmo is not “attached” to the geometry that it modifies anymore. During the workshop we already talked about other options (see the meeting notes) but couldn’t come to a final conclusion yet.
First, we have Gizmo A and Gizmo B colors in themes, and it feels weird that those are not allowed.
Yeah, we are aware of those colors. We decided not to include them at first because their name is a bit weird and does not convey any semantics (other than e.g. “Primary” and “Secondary”). We might add support for these theme options at some point, but maybe they should be renamed first.
As for actual gizmos, I would be happy with just two more things: First, a box. Just a box wireframe, because I have some modifiers that would benefit from concept of Cages, as we have with regular modifiers. And second is vector gizmos, three arrows for three directions.
For the second, see the image above. An ugly version of the cage gizmo can probably be build already. Would definitly be nice to add some more building blocks to be able to build a nice cage gizmo for sure. I think that still fits into the design nicely.
When I want to change strength of gizmo, I have to use Divide, instead of Multiply. Is that because it works right-to-left? Bit confusing.
Yeah that feels inverted at first, but is the only way it can work when using gizmos at a higher level. In the example below, we want the vector to change by 0.1 when the gizmo is moved by 1 unit.
I find it odd that this encourages modifying values inside node trees directly.
I don’t think it does, at least not any more than anything else we do. Like always, when you want things to be controllable outside from outside of your node group, at has to be group input. When working with linked node trees, you will only see the gizmos that are actually exposed (might not be implemented yet).
Internal gizmos are just a different way to modify values visually instead of changing sliders.
If an object has a gizmo and the user touches it, it will affect all objects using the same node group. I think that’s very counter-intuitive.
The response here is really the same as above. If you want a value to be constant with all uses of a node group, it has to stay local, otherwise just expose it as group input. The gizmos presented here are designed to make it very straight forward expose internal gizmos to the outside.
It would be nice (vital and expected, even) to have the ability to reset the property driven by the gizmo to a default value, eg. by right-clicking on it, or pressing some key combo while hovering over it.
Seems useful, but also sounds like a more general feature for Blender.
Would be great to be able to author gizmos such as the 2-axis translation gizmo (the little red/green/blue squares), as well as the 3-axis, camera-space gizmo (The center-most part of all 3 transformation gizmos).
The little squares are internally a drawing type for the arrow gizmo. I did not expose them yet, because the way they are drawn is a not unintuitive as an arrow gizmo. This gizmo shape could totally be exposed as well though.
I think Blender has some kind of drag gizmo that is dragged in screen space. That could be added as well, it will just be another gizmo node probably (one that controls a vector instead of a float though).
Idea: Store a transform matrix for each gizmo at the object level
Well, this may be a nightmare to implement, but I think it fixes all of the above.
I think this idea is not necessary given my response above. We shouldn’t have to store transform matrices for gizmos at all. That kind of goes against the idea that gizmos are just run-time UI that makes it easier to adjust settings.