Show gizmo while transforming #63743

New Issue

Campbell Barton · 2019-04-19T19:21:02+02:00

Campbell Barton commented

2019-04-19 19:21:02 +02:00

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.

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.

Campbell Barton commented

2019-04-19 19:21:02 +02:00

Added subscriber: @ideasman42

blender-admin commented

2019-04-19 19:21:02 +02:00

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

blender-admin commented

2019-04-19 19:21:02 +02:00

#82009 was marked as duplicate of this issue

blender-admin commented

2019-04-19 19:21:02 +02:00

#73844 was marked as duplicate of this issue

blender-admin commented

2019-04-19 19:21:02 +02:00

#73684 was marked as duplicate of this issue

blender-admin commented

2019-04-19 19:21:02 +02:00

#67825 was marked as duplicate of this issue

TheRedWaxPolice commented

2019-04-19 19:29:37 +02:00

Added subscriber: @TheRedWaxPolice

TheRedWaxPolice commented

2019-04-19 19:29:37 +02:00

Wonderful. I miss that functionality from other packages.

Regnas commented

2019-04-19 19:47:30 +02:00

Added subscriber: @Regnas

Regnas commented

2019-04-19 19:47:30 +02:00

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.

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 commented

2019-07-28 09:59:02 +02:00

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

William Reynish commented

2019-07-28 10:00:25 +02:00

Added subscriber: @WilliamReynish

William Reynish commented

2019-07-28 10:00:25 +02:00

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.

Kalyan commented

2019-09-15 08:05:42 +02:00

Added subscriber: @KalyanS

Kalyan commented

2019-09-15 08:05:42 +02:00

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?

Julian Eisel commented

2019-09-16 02:04:24 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2019-09-16 02:04:24 +02:00

@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).

William Reynish commented

2019-10-10 18:03:49 +02:00

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

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

Asher commented

2020-01-23 21:50:13 +01:00

Added subscriber: @ThatAsherGuy

Asher commented

2020-01-23 21:50:13 +01:00

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.

[P1227](https://archive.blender.org/developer/P1227.txt) 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.

Julian Eisel commented

2020-01-26 16:07:53 +01:00

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

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

William Reynish commented

2020-01-26 16:53:00 +01:00

Added subscriber: @yanguang

William Reynish commented

2020-01-26 16:53:00 +01:00

@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?

@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?

Debuk commented

2020-01-26 17:53:52 +01:00

Added subscriber: @Debuk

Debuk commented

2020-01-26 17:53:52 +01:00

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

Julian Eisel commented

2020-01-26 18:28:51 +01:00

@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

@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](https://archive.blender.org/developer/F8303298/recording.mp4)

Debuk commented

2020-01-26 23:19:01 +01:00

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

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

CobraA commented

2020-01-26 23:54:31 +01:00

Added subscriber: @CobraA

CobraA commented

2020-01-26 23:54:31 +01:00

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 : (

Asher commented

2020-01-27 01:09:22 +01:00

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.

> 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](https://archive.blender.org/developer/P1227.txt) 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.

Aaron Carlisle commented

2020-02-08 23:35:46 +01:00

Added subscriber: @unimbox

Aaron Carlisle commented

2020-02-15 23:26:34 +01:00

Added subscriber: @bblanimation

Jay Edwards commented

2020-02-17 21:59:57 +01:00

Added subscriber: @Jaye.Antoni_Whyldz

Salvador Garcia commented

2020-02-28 19:35:01 +01:00

Added subscriber: @seviscache

Salvador Garcia commented

2020-02-28 19:35:01 +01:00

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?

Pieter Schiettecatte commented

2020-02-28 20:11:53 +01:00

Added subscriber: @Schiette

Zsolt commented

2020-03-15 15:06:39 +01:00

Added subscriber: @Aurontwist

Adam Smith commented

2020-04-05 07:59:47 +02:00

Added subscriber: @Adam.S

Adam Smith commented

2020-04-05 07:59:47 +02:00

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.

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.

Hadrien Brissaud commented

2020-04-06 18:42:29 +02:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2020-04-06 18:42:29 +02:00

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

xan2622 commented

2020-04-06 22:26:49 +02:00

Added subscriber: @xan2622

ThinkingPolygons commented

2020-04-10 16:22:07 +02:00

Added subscriber: @ThinkingPolygons

ThinkingPolygons commented

2020-04-10 16:22:07 +02:00

@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. 🙁

@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. 🙁

Jonathan Brimer commented

2020-04-15 01:06:33 +02:00

Added subscriber: @counteragent

Russell commented

2020-04-19 19:46:34 +02:00

Added subscriber: @Russ1642

ThinkingPolygons commented

2020-04-19 21:15:46 +02:00

Added subscriber: @HooglyBoogly

ThinkingPolygons commented

2020-04-19 21:15:46 +02:00

@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. 😛

@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. 😛

Chris Kohl commented

2020-05-18 22:52:35 +02:00

Added subscriber: @ckohl_art

ThinkingPolygons commented

2020-07-31 00:31:18 +02:00

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

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

CobraA commented

2020-09-26 18:20:45 +02:00

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.

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

RedMser commented

2020-10-07 21:54:12 +02:00

Added subscriber: @RedMser

Adam Smith commented

2020-10-10 23:55:24 +02:00

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 😞

ThinkingPolygons commented

2020-10-17 05:30:12 +02:00

@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

@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

Germano Cavalcante commented

2020-10-23 22:19:09 +02:00

Added subscriber: @DrMc

Robert Guetzkow commented

2021-02-07 23:46:49 +01:00

Added subscribers: @Hunanbean, @rjg

Oskar commented

2021-05-28 15:24:15 +02:00

Added subscriber: @TRBRY

Volo commented

2021-06-14 23:53:22 +02:00

Added subscriber: @hadouken

Sarah Laufer commented

2021-07-30 12:19:56 +02:00

Added subscriber: @feldlaufer-4

Sarah Laufer commented

2021-07-30 12:19:56 +02:00

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.

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

Max Derksen commented

2021-09-20 18:35:51 +02:00

Added subscriber: @derksen

blender-admin commented

2022-06-05 15:09:33 +02:00

This issue was referenced by 648350e456

This issue was referenced by 648350e456490f8d6258e7de9bf94d3a6a34dbb2

Campbell Barton commented

2022-06-05 15:26:05 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2022-06-05 15:26:05 +02:00

Campbell Barton self-assigned this 2022-06-05 15:26:05 +02:00

Royster commented

2022-06-06 15:34:40 +02:00

Added subscriber: @Royston

Royster commented

2022-06-06 15:34:40 +02:00

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.

Mat Brady commented

2022-06-28 05:57:54 +02:00

Added subscriber: @MatBrady

Mat Brady commented

2022-06-28 05:57:54 +02:00

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

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

CobraA commented

2022-09-09 16:01:01 +02:00

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 :(

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 :(

Alex commented

2022-11-21 20:41:51 +01:00

Added subscriber: @SpectreFirst

Alex commented

2022-11-21 20:41:51 +01:00

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.

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.

Sign in to join this conversation.

32 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#63743

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Show gizmo while transforming #63743