The dial gizmo snaps to zero on full rotations:
5 Likes
I really haven’t found a satisfactory answer to this question… So it’s pointless answering the previous one.
However, it seems to me that associating a geometry with a gizmo could be relevant.
For example, to make Sliders, Bends or UIs.
Geometry wouldn’t be interactive, just aesthetic.
I don’t yet know how to integrate it, perhaps with a geometry input at the gizmo.
2 Likes
It happens randomly when I tweak a gizmo or when I change the node tree. I can do the same step several times without issue. But sometimes, suddenly blender freezes.
Try one this one …
Grap some gizmos, tweak them randomly. On my machine, Blender suddenly freezes sometimes.
Something’s bothering me about the transform: why allow multiple connections?
If multiple connections are allowed, why not duplicate the gizmo to each join geometry. This is not a “dynamic” duplication?
Why does a geometry transform only work if it’s linked to a geometry?
We could edit the Gizmo transformation without using the input parameters of Gizmo.
Why is the transform output called transform and not gizmo?
You could even imagine a new “set gizmo color/theme” node with a geometry input, to avoid setting up the color in the arrow gizmo. Or “Set Scale mod (World/Screen)”
The transform is behaving very strangely…
It just needs to be linked to the output.
You got an interesting point. After a gizmo got plugged to a geometry flow, one could do some ambiguous mess with it …
Now, what is the correct transformation for the gizmo?
That’s a valid point. It’s essentially the same topic that’s already mentioned in the original post for instances. Currently, the gizmos only show for the first instance. In theory we could use different heuristics, but it’s likely something that needs to be user-configurable at some point. We don’t really always want to show the gizmos multiple times I think, as this could overload the viewport with potentially redundant information.
I haven’t implemented it explicitly for the Join node yet, but I’d assume that the earlier inputs currently have precedence over the later inputs.
Also see the last point of the gizmo section of our workshop meeting notes.
We generally want to retrieve the gizmos transforms from the geometry that’s shown in the viewport. I still have to support looking up the transforms correctly when the Viewer node is used.
If the transform output is not used, it’s also not part of a geometry that’s shown in the viewport, so it’s ignored.
It was called Gizmo in my original implementation, but we changed that at some point because the gizmo can exist without this output being used, and it’s technically only the “Gizmo Transform”, even on the code level. We skipped the “Gizmo” part of the name, because it’s redundant of the node name.
That could be implemented with the current design in theory, but it doesn’t seem to solve a problem so far.
1 Like
As mentioned, I believe that it’s really use-case dependent whether the gizmos can and should be build separately from the rest of the node tree. If the kinds of gizmos you build require the “Grape Bunch Workflow”, then it would be very annoying to have to duplicate nodes. Portal links might help eventually to separate gizmos from the rest of the tree a bit more visually.
Indeed, will have to fix that.
Could be done, but generally it would be good if the gizmo can be placed somewhere on the geometry where the association is clear without extra geometry.
Gizmos that just act as a new kind of slider that shows up in the viewport but has no spatial correspondence to the geometry are out of scope currently.
I couldn’t reproduce the issue with this file yet unfortunately. Maybe it’s fixed already in a new build, don’t know. If not, please keep an eye open and try to remember more exactly what you did before it crashed.
1 Like
I used PR112677.29540a2f8d8a. There seems to be a pattern. If no node in the GN tree is selected, I can tweak gizmos. But the moment I select a node, freeze happens.
I try PR112677.9d7cd68b5533 now. I can tweak gizmos and select nodes, no freeze happened so far.
Thank you Jacques for taking the time to reply
Now bug and crash report!
The gizmo disappears if I duplicate the geometry node:
I crash if I use CTRL + Z
Next
I wanted to make a dynamic constraint system.
For this I used a Maximum, I wanted the gizmo to block when it equals the inner radius.
Do you think this can be implemented?
Then I tried to modify 3 inputs with a Gizmo that have different constraint values.
The gizmo locks at the minimum value, which I find counter-intuitive.
Shouldn’t he behave this way?
Edit: I realize that this is a general problem.
1 Like
I have other questions, I understand why transforms don’t work after gizmo if they’re not linked to geometry.
But why aren’t they automatically connected to the geometry at the end of the node graph when it’s not linked?
In what context is it irrelevant to link the gizmo to the end of the geometry?
Better to do it all the time by default?
If it’s imperative to be able to choose, why not set a parameter in the group node, “ignore unlinked transforms”?
Edit: even better, add an option. Relative / World in gizmos. It is Relative by default.
Relative: the gizmo is connected to the end of the node graph.
Absolute: the gizmo is not connected to the geometry.
If you connect the transform to the geometry, the parameter disappears. It is necessarily in “relative”.
So even people who create assets wouldn’t have to worry about it.
That would be a plus for readability, I think.
Secondly, I think the space after the gizmo should always be considered, even if it’s not connected.
It’s sometimes simpler to use a series of transforms to modify a position.
(If dupplications are supported)
To achieve this configuration, I think it’s more flexible to do it this way
(Currently)
It seems important to me that the space after the transform should always be considered.
I’m curious if there are any user personas created for Gizmos.
Having a Gizmo tell its function by type, placement, and direction demonstrates a desire for simplicity. This level of simplicity could make some Blender use cases easy(er) for non-Blender users to step into (e.g. non-Blender user creating small 3D world for VR or to be turned into TTRPG maps.) I doubt my example is the current goal. User personas would help guide my feedback.
What does that mean ? user personas ?
I hope it does not mean that you like to gather some statistics about what users do with a tool?
No, it looks he just means different user skill level profiles, which set the interface and tools up for either basic or advanced abilities.
Not within the scope of this thread.
2 Likes
That’s correct. I assume the use case I keep thinking of (users with a limited experience within Blender using it for layout and blocking and limited customization) is not the current goal. If I understand the current goal I will be less likely to distract the conversation.
Are there official targeted personas, goals or parameters we are trying to work within?
User Personas are a technique for business process design, general UI/UX design, as well as marketing. It helps to ensure the creators are focused on the end goal of how and where a product will be used.
A simple example would be creating a tool for executives to visualize time series data. You would want to remove as many windows, menus, and overlays as possible and make the available actions appear obvious and intuitive. Taking that idea further, if I was using Blender as the base for that tool, I would disable most shortcut keys, while also providing a way for the executive to incrementally look behind the curtain to see the power that resides just below the surface.
Reference
Persona (user experience) - Wikipedia
I sometimes shy away from sharing links to Wikipedia as people can take it wrong, but this is a good primer
Definitely not. It is about making sure everyone one developing an item is on the same page, working towards solving the same problem. While Microsoft and Google - as well as any application that asks for “anonymized usage data” - are clearly doing this, I personally dislike that approach. User Personas can be prepared without all of the data collection.
2 Likes
Alright, thanks for the explanation. No worries at all. It sounds a bit like “Blender Apps” : Blender Apps — Developer Blog
I have tested again on latest build and I’ll leave some minor feedbacks:
-
Pin Gizmo Icon is clickable only in node tree itself, on the first value in gizmo-chain(?). But if that first value is group input node and icon appears in modifier, I expect that icon to be clickable in modifier too, but its not. Probably something you haven’t implemented yet, but still.
-
Icon is displayed on every node before Gizmo node, but not after it. I know its tricky and I dont even know if its a good idea. But maybe icons should be displayed on every node that is recieveing value that is recieving a gizmo?
In here since Combine XYZ is controlled by value that is controlled by gizmo, I’m expecting two things: A) icon (not clickable), and when I select the node gizmo to appear if its not pinned. It feels weird that you select actual node that changes translation and gizmo doesnt appear because its technically somewhere on the left of the chain. -
Dial Gizmo resetting after 360 rotation is still there.
-
Dial Gizmo shouldn’t be visible here, its not connected to anything and isnt selected, but cant get rid of it
-
I suggest moving “Active Modifier” above “Active Object” in the Gizmos popover panel, because directly below there are options “Object Gizmos”, which are enabled if Active Object is enabled, so its important that link between them is obvious and there isnt anything in between that is unrelated.
-
Gizmo icon greying out should happen when value has a driver on it. And cherry on the top would be if hovering over the icon gave you reason why gizmo isnt working.
-
Once again, please move Gizmos category in Utilities :') Add menu is getting too tall, we now have Normals and Gizmos on top of what it was in last version, Its getting unmanagable.
-
This is triggering something in me
Correct way to draw this is:
But to go back to the overall design and something I proposed earlier. When you make node group with just a gizmo on it, and pass input value unchanged as output, you can have a gizmo that on user level doesnt go backwards and you can simply drop on the line you want to affect. Its perfect.
So I’m thinking why not add that functionality to the gizmo node itself? When you plug in value, Output socket Value appears that just outputs value without changing it, dummy value kinda. That way you can drop that gizmo on the line and it will save you trouble of connecting same thing to gizmo and input you want to change, and more importantly having to understand design behind this.
Problem with this is that since gizmos are multi input sockets, which value is it outputting? How about having some sort of dynamic outputs, meaning it creates as many value outputs as you have inputs. If you have 3 values inputted, it creates 3 outputs, Value 1, Value 2, Value 3. Order is determined by order in which they’re inputted. To better control the order I think in node properties panel tree-view can be added, which lists all inputs in multi input socket (this is something I’ve wanted for join geometry too). So that you can drag and create your order. If you have 3 inputs and unplug one of them, one of the outputs just disappears. If you input it again, it appears again.
I know this is a lot of work I’m asking for, but I think it can make gizmos as user-friendly and easy to understand as they can get.
@nickberckley Thanks for the feedback. I implemented some of it, some was already implemented because the build was not updated, and some things are too tricky for now or I don’t agree. More details below.
Indeed something that’s just not implemented yet, and we also haven’t defined the exact behavior this should have yet. I’m sure that’s something we’ll add at some point in some way.
That doesn’t seem to scale well, because it wouldn’t be clear where to stop propagating the gizmo. Like, should everything that comes after the Vector output also have the gizmo icon? It looses its usability if it’s shown in too many places. Currently the icon also indicates that when you connect something to it, the gizmo will be propagated to the left, which wouldn’t be the case anymore.
That was fixed in 808e8dbfe7.
As described, a gizmo is visible if the “raw” built-in gizmo node is in the open node tree. When I wrote the explanation for how the system works, I found this behavior to be much more useful because it’s less frustrating when the gizmo doesn’t disappear all the time.
It’s still possible to get rid of the gizmo in two ways: either you mute the gizmo node, or you put it into a node group.
Done.
Would be nice, but that’s a bit more complex for me right now unfortunately, because the animation system is taken into account at a separate stage of drawing the ui, that I didn’t touch yet. Sounds like something we’ll do eventually.
I already moved it to the Input submenu. That seemed reasonable.
Done. At least I improved it in a couple of situations. I’m sure more improvements are possible in the future.
Ah forgot to respond to that earlier. This was actually part of an earlier design iteration but we removed the output, because it confuses the core design and makes it more look like the gizmo node actually contains the value. I do think it’s a great idea to build node groups that actually act as input values though (like your “Z Location Gizmo” group), but that’s a special case of the design. We are considering to put some of those into the essentials asset bundle.
2 Likes