Show gizmo while transforming #63743

Closed
opened 2019-04-19 19:21:02 +02:00 by Campbell Barton · 70 comments

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

Added subscriber: @ideasman42

Added subscriber: @ideasman42

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

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

#82009 was marked as duplicate of this issue

#82009 was marked as duplicate of this issue

#73844 was marked as duplicate of this issue

#73844 was marked as duplicate of this issue

#73684 was marked as duplicate of this issue

#73684 was marked as duplicate of this issue

#67825 was marked as duplicate of this issue

#67825 was marked as duplicate of this issue

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

Wonderful. I miss that functionality from other packages.

Wonderful. I miss that functionality from other packages.

Added subscriber: @Regnas

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.

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 subscribers: @hopeinformer, @runswithfork, @GavinScott, @AbidMaqbool

Added subscriber: @WilliamReynish

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.

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

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?

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

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

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

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

@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

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.

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

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

Added subscriber: @yanguang

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?

@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

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.

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

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

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

Added subscriber: @CobraA

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

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.

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

Added subscriber: @unimbox

Added subscriber: @unimbox
Member

Added subscriber: @bblanimation

Added subscriber: @bblanimation

Added subscriber: @Jaye.Antoni_Whyldz

Added subscriber: @Jaye.Antoni_Whyldz

Added subscriber: @seviscache

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?

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: @Schiette

Added subscriber: @Aurontwist

Added subscriber: @Aurontwist

Added subscriber: @Adam.S

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

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

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: @xan2622

Added subscriber: @ThinkingPolygons

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

@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: @counteragent

Added subscriber: @Russ1642

Added subscriber: @Russ1642

Added subscriber: @HooglyBoogly

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

@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

Added subscriber: @ckohl_art

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

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.

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

Added subscriber: @RedMser

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 😞

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

@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 subscriber: @DrMc

Added subscribers: @Hunanbean, @rjg

Added subscribers: @Hunanbean, @rjg

Added subscriber: @TRBRY

Added subscriber: @TRBRY

Added subscriber: @hadouken

Added subscriber: @hadouken

Added subscriber: @feldlaufer-4

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

Added subscriber: @derksen

This issue was referenced by 648350e456

This issue was referenced by 648350e456490f8d6258e7de9bf94d3a6a34dbb2
Author
Owner

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Campbell Barton self-assigned this 2022-06-05 15:26:05 +02:00

Added subscriber: @Royston

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.

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

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

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

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

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.

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.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
32 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#63743
No description provided.