Page MenuHome

Show gizmo while transforming
Confirmed, NormalPublicTO DO

Tokens
"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.
Assigned To
None
Authored By

Description

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.

Event Timeline

Wonderful. I miss that functionality from other packages.

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.

William Reynish (billreynish) raised the priority of this task from Low to 50.EditedJul 28 2019, 9:59 AM

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.

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).EditedSun, Jan 26, 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.EditedSun, Jan 26, 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.