Show gizmo while transforming #63743

Animators in the Blender studio requested to show the gizmo while transforming since it can be helpful to see the axis.

This could be optional since you might not always want to see the gizmo.

Added subscriber: @ideasman42

blender/blender-addons#85457 was marked as duplicate of this issue

#82009 was marked as duplicate of this issue

#73844 was marked as duplicate of this issue

#73684 was marked as duplicate of this issue

#67825 was marked as duplicate of this issue

Added subscriber: @TheRedWaxPolice

Wonderful. I miss that functionality from other packages.

Added subscriber: @Regnas

Awesome awesome awesome.
Too bad it's low priority. This is highly needed.
Also, since the gizmo stays visible when transforming, there's no need to display those infinite axis lines. I always wondered if there was a way to turn those lines off.

Anyway, can't wait to see it working.

Added subscribers: @hopeinformer, @runswithfork, @GavinScott, @AbidMaqbool

Added subscriber: @WilliamReynish

Upping this to medium priority, since we hear loads of requests for this. Especially with the viewpoint gizmo, you don't expect part of the UI to disappear while transforming.

Added subscriber: @KalyanS

Hi, I'd like to work on this if that's ok. Any pointers on where the related code is/how to accomplish this? Also, should jut the gizmo be visible or do we want to keep all the UI items visible?

Added subscriber: @JulianEisel

@KalyanS I wouldn't recommend this for someone just getting into Blender development, this is a harder task than it appears to be. Issue is a) getting the updated transform data (previously you had to force an update of the object matrices to solve this, potentially duplicating work with viewport drawing - the new depsgraph might make this simple to solve), and b) efficiently recalculating the gizmo position (calculating its position with 1000's of vertices selected can be expensive).

@JulianEisel I think in most other apps, the gizmo transform isn't inferred from the transformed elements - if anything it's the other way around. Just like the mouse cursor location isn't derived from the transformed items, but the items are transformed based on the cursor movement.

In Blender, the gizmos transform seem to be handled backwards.

Added subscriber: @ThatAsherGuy

P1227 is a quick and dirty hack that keeps the transform gizmo visible during modal events. All I've really does is comment out the bits of code that explicitly disable the transform gizmo during modals, and add the WM_GIZMOGROUPTYPE_DRAW_MODAL_ALL flag to its gizmo group to keep it from disabling the viewport navigation gizmo.

Should I find a less expensive way to do this? @JulianEisel, your comments about the complexity of the task have me wondering if there's something I've missed.

@ThatAsherGuy the issue is not so much getting them to show. If we show them, we need to make sure the position is updated correctly though and with the current code design that may be an expensive operation to do. We may have to iterate over thousands of objects or vertices each redraw (so each time the mouse moves slightly) and calculate the centroid.
That is added to the work the transform operator already does. The gizmos can currently not access the transform operator data, which is the only place containing the transform deltas. To solve this in an efficient way, the transform manipulator would need access to these deltas somehow, which may require some refactoring.

Added subscriber: @yanguang

@JulianEisel although arguably we shouldn’t even need to recalculate the gizmo positions during transform, based on the transformed data. Doing so would be slow and seems unnecessary. Instead, the gizmos could simple be transformed independently, surely?

I tried @ThatAsherGuy’s patch and could not really notice any problems, nor any apparent slowdown. Are there any concrete examples why that would not be sufficient?

Added subscriber: @Debuk

@JulianEisel I also think such a recalc is unneccessary. A change for a centroid's position that differs from the transform itself is just neccessary if the considered elements change their relative position to each other. That's neither the case for multiple objects nor face, edge or vertex positions. Also in the case of proportional editing the selected elements keeps their relative positions and the unselected transformed ones are not relevant for the gizmo. So I also don't see a concrete cae for a recalc needed. Perhaps we are overlooking a special case, but shouldn't that be treated as a special case for the sake of performance anyway then? So if such a case exists we could also deactivate the cursor for that case until it can be adressed.

@WilliamReynish there are a few things that may affect transform though, that the independent gizmos would have to respect too: precision ({nav Shift}-) dragging, snapping, changes in axes constraints, etc. Basically all options the user can change while transforming affect the transform value, so the gizmos would have to respect them too. AFAIK Anthony tried getting this approach to work during Gooseberry, but decided that it's not a good idea.

@Debuk I considered that too (calculating the delta transform based on the first selected item found) but that won't work reliably either. There are cases were different selected items transform differently. E.g. in object mode, individual objects can have different axes locked, so while one object is free to move in any direction, another may have the X and Y axes locked. You can't lock vertices in edit mode, but there are still cases when they may transform differently. Like if a mirror modifier is applied with clipping enabled. Note how the left vertices don't move and could therefore not be used to calculate the transform delta:
recording.mp4

@JulianEisel Ok, you're right,that are indeed cases I've overlooked.

But it made me think about what's the expected behaviour in these specialcases. Did you discuss these specialcases internally already?

Is it really a good idea to calculate the centroid in these cases? Sure a gizmo is expected to be there at the start, but I think while the mouse is moved the gizmo should continue to be transformed linear extrapolated along the the current intended movement direction (restricted or not), it should rather visualize the current "target" position, regardless if that's reachable for individual verts or not. In the case you demoed ( or a subdivided version of it) a gizmo would slow down the more points converge into the mirrorplane.

Personally I think that would feel strange during a drag.

As a positive sideeffect you would also not have to do such potentially heavy calculations in realtime while the drag is done. And when the mouse is released, the gizmo would be placed exactly where it is in the current implementation.

Overall it would be comparable to the current possible offset between the mouse cursor and the gizmo if eg the cursor is moved along the x axis while the mouse is also moved vertically just that it would be an "offset" between the verts and the gizmo.

Anyhow. This still would need access to the transform delta.

Added subscriber: @CobraA

I know this is maybe too early to discuss but i hope you guys take into account the sensitivity when draggin from the Gizmos axes, they're super sensitive when it's close to the origin and maybe we can get a better color highlighting along the way too, I can't see the axes highlight except for the white circles : (

The gizmos can currently not access the transform operator data,

We could follow the mold set by drawDial3d() and build a secondary modal-only gizmo. It'd take some grunt work, but it wouldn't be conceptually complex and it'd give us a way to tune how the gizmo looks and feels in-motion. P1227 isn't a plug-and-play option for transforms using normal orientation or rotations around the bounding box center, in any case; won't take much for us to end up with enough modal-only logic to merit making a separate gizmo.

Added subscriber: @unimbox

Added subscriber: @bblanimation

Added subscriber: @Jaye.Antoni_Whyldz

Added subscriber: @seviscache

I understand that Gizmo is a visual representation of the transformation, as they mention, having another gizmo or an object that looks like the gizmo that copies the transformations of the selection?

Added subscriber: @Schiette

Added subscriber: @Aurontwist

Added subscriber: @Adam.S

Hello Developers.
Someone has pointed me to this task awhile ago, not sure if it's the appropriate place to ask for improvements but i had made a thread about it on BlenderArtists if you can kindly check it out.
https://blenderartists.org/t/blenders-3d-manipulators-for-animators/1199990

It's aligned with this project and the main points are.

Better Preselection Highlight for the axes, a different Color maybe.
Always visible during Transformation.
Quick resizing with two hotkeys.
more customization options like in this image.

Added subscriber: @hadrien

To me it seems the gizmo just needs to follow the input transform values. @JulianEisel in your example, showing the gizmo while transforming and continually updating its position to match the selection's center of mass would probably look like it's lagging behind the mouse cursor. In my opinion as an artist, it seems okay to update it according to the input transform values while the operator is running, and then recalculate its position once the transformation is done (just like we do now).

Added subscriber: @xan2622

Added subscriber: @ThinkingPolygons

@JulianEisel There's really nothing that can be done for it to work at least in sculpt mode for the time being?
This functionality is really crucial there. 🙁

Added subscriber: @counteragent

Added subscriber: @Russ1642

Added subscriber: @HooglyBoogly

@HooglyBoogly I heard you're now doing UI work, so I hope you can tackle this precious task. I think you got the skills, am I right? hehehe

And sorry for the ping. 😛

Added subscriber: @ckohl_art

Papercut?
This issue really looks a lot more serious than that.

In #63743#988003, @ThinkingPolygons wrote:
Papercut?
This issue really looks a lot more serious than that.

It really baffles me why it'snot done like any Standard DCC even Marmoset toolbag, UE4, Unity... have standard transform gizmos that are even good for animating & sculpting, i guess this is the curse of open source every important feature is pushed back just like OpenSubdiv on GPU which we have been waiting for more than a year to see it brought back.

Added subscriber: @RedMser

It looks like we're going to wait for another "big milestone" (many years from now ) before we can see this in Blender, similar to moving the origins. which took like what! 10 years or more 😞

@CobraA @Adam.S Please don't destroy my hopes guys 😂 my fingers are crossed day and night for this. 🤞
That's the best thing since sliced bread

Added subscriber: @DrMc

Added subscribers: @Hunanbean, @rjg

Added subscriber: @TRBRY

Added subscriber: @hadouken

Added subscriber: @feldlaufer-4

1 for this. It is really weird that gizmos and object transformations seem to be 2 separate things. For the natural behaviour should be, I press R, and gizmo of rotation is activated. I can use it or just use R like normal, but at least its consistent, I see the gizmo of the transform I triggered.

Added subscriber: @derksen

This issue was referenced by 648350e456

Changed status from 'Confirmed' to: 'Resolved'

Added subscriber: @Royston

Would be nice to see this working again like it used too. At the moment it seems you cannot keyframe an object by moving it around by hand. (pressing play and autokey in the timeline) Or at least an option to turn on manipulators visibility during anim playback.

Added subscriber: @MatBrady

This add-on which was released only in the last couple of weeks, actually solves this issue in a more elegant way. You don't want to see the gizmo while you're in modal operations, but this add-on allows both.
https://blendermarket.com/products/gizmodal-ops

Mmmm, this seems like half done stuff, not so good at all.
It needs a redesign to be more user friendly, u should take inspiration from what it works in other DCCs and make them fit within blender style instead of just a quick fix that makes it too messy :(

Added subscriber: @SpectreFirst

I see that this function was implemented in 3.0 ("Navigation gizmos no longer hide when using modal operators (917a972b56)") but I have a question - is it possible to disable this and bring back the old behavior when only an axis was visible during movements? The reason why I'm asking this is because sometimes it becomes very uncomfortable to work with manipulator gizmo because it starts to obstruct small details and it becomes harder to see what you are doing. Logically there should be an option like "Persistent Gizmo" or something like that somewhere in Preferences but I couldn't find it anywhere.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Show gizmo while transforming #63743