Page MenuHome

Show gizmo while transforming
Closed, ResolvedPublicTO DO

Authored By
"Love" token, awarded by Derksen."Heartbreak" token, awarded by hadrien."Like" token, awarded by ncotrb."Love" token, awarded by Harti."Love" token, awarded by DotBow."100" token, awarded by Frozen_Death_Knight."Like" token, awarded by VertexSupa."Love" token, awarded by russ1642."Love" token, awarded by Tetone."Like" token, awarded by JayE01."100" token, awarded by Adam.S."Burninate" token, awarded by Chromauron."Like" token, awarded by Schiette."Love" token, awarded by Shimoon."Baby Tequila" token, awarded by craig_jones."Love" token, awarded by bblanimation."100" token, awarded by cruelandunusual."100" token, awarded by CobraA."Mountain of Wealth" token, awarded by xrg."Love" token, awarded by billreynish."Like" token, awarded by sh4dowk4ge."Like" token, awarded by amonpaike."Like" token, awarded by jc4d."Love" token, awarded by bnzs."Like" token, awarded by cto.abid."Love" token, awarded by Zino."Love" token, awarded by elbox01."Like" token, awarded by Regnas."Love" token, awarded by TheRedWaxPolice.


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.

Revisions and Commits

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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?

@Kalyan (coder.kalyan) 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).

@Julian Eisel (Severin) 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.

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? @Julian Eisel (Severin), your comments about the complexity of the task have me wondering if there's something I've missed.

@Asher (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.

@Julian Eisel (Severin) 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 @Asher (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?

Debuk (Debuk) added a subscriber: Debuk (Debuk).EditedJan 26 2020, 5:53 PM

@Julian Eisel (Severin) 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.

@William Reynish (billreynish) there are a few things that may affect transform though, that the independent gizmos would have to respect too: precision (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 (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:

Debuk (Debuk) added a comment.EditedJan 26 2020, 11:19 PM

@Julian Eisel (Severin) 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.

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.

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?

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.

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

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

To me it seems the gizmo just needs to follow the input transform values. @Julian Eisel (Severin) 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).

@Julian Eisel (Severin) 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. 🙁

@Hans Goudey (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. 😛

This issue really looks a lot more serious than that.

CobraA (CobraA) added a comment.EditedSep 26 2020, 6:20 PM

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.

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 (CobraA) @Adam Smith (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

+ 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.

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.

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.