Improve visualization when dragging Move/Scale Gizmos #103782

Closed
opened 2023-01-10 14:55:25 +01:00 by Julien Kaspar · 32 comments
Member

Since recent releases the Transform gizmos for for Move and Scale are always visible when dragging them.
This can add visual clutter, so it would be best to reduce the visible gizmo to only the dragged element (Similar when draggin the Rotate gizmo)

A visual example of how this could look like:
gizmo_vis2.png

Another change could be to simplify the gray ghost element that marks the original location of the gizmo.
This could instead be a subtle gray dot.

Since recent releases the Transform gizmos for for **Move** and **Scale** are always visible when dragging them. This can add visual clutter, so it would be best to reduce the visible gizmo to only the dragged element (Similar when draggin the **Rotate** gizmo) A visual example of how this could look like: ![gizmo_vis2.png](https://archive.blender.org/developer/F14137580/gizmo_vis2.png) Another change could be to simplify the gray ghost element that marks the original location of the gizmo. This could instead be a subtle gray dot.
Author
Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Author
Member

Added subscribers: @JulienKaspar, @ideasman42

Added subscribers: @JulienKaspar, @ideasman42

Added subscriber: @torrent-1

Added subscriber: @torrent-1

I prefer the current behavior (always visible).

Very often when dragging the gizmo on an axis, I keep an eye on the rest of the gizmo for precise positioning/measurements purposes. Very useful.

I honestly don't see any clutter. This is how it behaves on most 3d software and never saw anyone complaining.

Please don't ruin it.

I prefer the current behavior (always visible). Very often when dragging the gizmo on an axis, I keep an eye on the rest of the gizmo for precise positioning/measurements purposes. Very useful. I honestly don't see any clutter. This is how it behaves on most 3d software and never saw anyone complaining. Please don't ruin it.

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

I think this will allow to focus on your selection during operations, which is useful during working with dense meshes and objects with complex irregular structures and tiny details at the distances that not exceed the size of a gizmo.
How it is supposed to look when using two axis transform (for example, XZ)?

It may be a 3-levels option preference (full gizmo, the proposed partial gizmo, no gizmo during operation)
For example, during linear/CAD modeling working set I would prefer to have the ability to see full or partial gizmo during operation because of a local transforms, but during organic modeling or animation working set I would prefer to see the resulting composition without visual influence of a gizmo during operation.

I think this will allow to focus on your selection during operations, which is useful during working with dense meshes and objects with complex irregular structures and tiny details at the distances that not exceed the size of a gizmo. How it is supposed to look when using two axis transform (for example, XZ)? It may be a 3-levels option preference (full gizmo, the proposed partial gizmo, no gizmo during operation) For example, during linear/CAD modeling working set I would prefer to have the ability to see full or partial gizmo during operation because of a local transforms, but during organic modeling or animation working set I would prefer to see the resulting composition without visual influence of a gizmo during operation.

Changed status from 'Confirmed' to: 'Needs User Info'

Changed status from 'Confirmed' to: 'Needs User Info'

@JulienKaspar this proposal seems OK in isolation.

Would this also apply to scale? Dragging the planes to change 2 axes at once has some advantage in showing the single axes too.

Checking if this proposal is to change "Move" and leave the scale gizmo as-is.

@JulienKaspar this proposal seems OK in isolation. Would this also apply to scale? Dragging the planes to change 2 axes at once has some advantage in showing the single axes too. Checking if this proposal is to change "Move" and leave the scale gizmo as-is.
Author
Member

@ideasman42 Yes this proposal is also for the Scale gizmo.

@1D_Inc I agree. Also when using two gizmo handles at once (XY for example), we should highlight keep both axes visible.
@torrent-1 An option in the preferences to always show all axes when dragging the gizmo can be added if there's the need for it (As well as an option to always hide the gizmo completely).
But this design is just on making the gizmo clearer and remove clutter. Then we can see if the other options are really needed.

Maybe the gizmo can be made even clearer when using only a single axis: Like this:
Screenshot_2021-08-31_10-48-tyuytu.png

So the important visual info is always:

  • The used gizmo handles
  • The current transform pivot (With a colored dot or white circle)
  • The original pivot location (Gray dot)
@ideasman42 Yes this proposal is also for the Scale gizmo. @1D_Inc I agree. Also when using two gizmo handles at once (XY for example), we should highlight keep both axes visible. @torrent-1 An option in the preferences to always show all axes when dragging the gizmo can be added if there's the need for it (As well as an option to always hide the gizmo completely). But this design is just on making the gizmo clearer and remove clutter. Then we can see if the other options are really needed. Maybe the gizmo can be made even clearer when using only a single axis: Like this: ![Screenshot_2021-08-31_10-48-tyuytu.png](https://archive.blender.org/developer/F14141309/Screenshot_2021-08-31_10-48-tyuytu.png) So the important visual info is always: - The used gizmo handles - The current transform pivot (With a colored dot or white circle) - The original pivot location (Gray dot)

Added subscriber: @Regnas

Added subscriber: @Regnas

I'm sorry but I don't understand.

It took blender long enough to implement that precious industry standard feature. And now this?
This is basically removing the feature. I don't get it.

Clutter? Since when? This is literally the transform gizmo, and it's doing what it's meant to.

If some people doesn't want to see or interact with gizmos, then they probably should use the modal tools, not destroy the standard gizmo workflows.

It really makes no sense to me. There's a reason why this feature was highly requested as is. Oh well.

Please make it optional. Thank you.

I'm sorry but I don't understand. It took blender long enough to implement that precious industry standard feature. And now this? This is basically removing the feature. I don't get it. Clutter? Since when? This is literally the transform gizmo, and it's doing what it's meant to. If some people doesn't want to see or interact with gizmos, then they probably should use the modal tools, not destroy the standard gizmo workflows. It really makes no sense to me. There's a reason why this feature was highly requested as is. Oh well. Please make it optional. Thank you.
Author
Member

@Regnas Can you elaborate why seeing the entire gizmo is useful?
If it makes a conversation easier, you can also tag me in the user-interface chat instead.

@Regnas Can you elaborate why seeing the entire gizmo is useful? If it makes a conversation easier, you can also tag me in the [user-interface chat](https://blender.chat/channel/user-interface) instead.

Changed status from 'Needs User Info' to: 'Confirmed'

Changed status from 'Needs User Info' to: 'Confirmed'

@JulienKaspar in that case the proposal LGTM. Although there are some details that seem not to be settled on.

I'll keep the option open to show the entire gizmo, although I'd rather avoid the preference if possible.

@JulienKaspar in that case the proposal LGTM. Although there are some details that seem not to be settled on. I'll keep the option open to show the entire gizmo, although I'd rather avoid the preference if possible.

Added subscriber: @mano-wii

Added subscriber: @mano-wii

In #103782#1472303, @torrent-1 wrote:
I prefer the current behavior (always visible).

Very often when dragging the gizmo on an axis, I keep an eye on the rest of the gizmo for precise positioning/measurements purposes. Very useful.

I honestly don't see any clutter. This is how it behaves on most 3d software and never saw anyone complaining.

Please don't ruin it.

If we don't replace the "gray ghost element" with the "subtle gray dot", it doesn't disturb this visual precise positioning/measurements (as far as I could test).
The ghost of the selected gizmo is still visible and can be used for the same purpose:
Jan-25-2023 13-12-59.gif

> In #103782#1472303, @torrent-1 wrote: > I prefer the current behavior (always visible). > > > Very often when dragging the gizmo on an axis, I keep an eye on the rest of the gizmo for precise positioning/measurements purposes. Very useful. > > I honestly don't see any clutter. This is how it behaves on most 3d software and never saw anyone complaining. > > Please don't ruin it. If we don't replace the "gray ghost element" with the "subtle gray dot", it doesn't disturb this visual precise positioning/measurements (as far as I could test). The ghost of the selected gizmo is still visible and can be used for the same purpose: ![Jan-25-2023 13-12-59.gif](https://archive.blender.org/developer/F14197665/Jan-25-2023_13-12-59.gif)

Added subscriber: @ThinkingPolygons

Added subscriber: @ThinkingPolygons

In D17115#468758, @ThinkingPolygons wrote:
@JulienKaspar Just imagine moving horizontally to align points vertically for example.

blender_8iZ5OYoWAS.mp4

Without the visible gizmo axes when transforming, there would be too much guess work/errors because of the distance of the points and also too much click drag and release to see if the gizmo is aligned.

Might look minor but aligning things using the gizmos axes happens a lot in several situations. I hope you understand what I mean.
So like I said, what you have here would be ok for the multi transform tool. A contrast to the traditional transform gizmos.
Or just make it optional and everybody wins.


In D17115#468829, @mano-wii wrote:
The description shows a very specific and rare usage that is not intended for this gizmo.
This is most expected to be aided by the grid and other forms of precision modeling.
Furthermore, this is only useful in orthographic views and the gizmo is rarely large enough to accurately point to a desired point in the scene.

I don't think it's worth keeping the gizmo or adding an option to the preferences for such a use.


In D17115#468830, @JulienKaspar wrote:
@ThinkingPolygons Thanks for the example!
An alternative workflow to this could be snapping. As it doesn't require you to zoom out and align the gizmo with what your are seeing.
So you could drag the x axis -> Hold Ctrl to snap the center to a vertex or surface.

| image.png | image.png | image.png

But I understand how the gizmo can intuitively be used to eyeball alignments instead of using exact snapping.
It's something to think about ...


In D17115#468834, @ThinkingPolygons wrote:
@ germano, that’s not a rare use case at all.
@ kaspar, of course there are several slightly more complicated workarounds for that, but we are losing quality of life here. Things that used to be straightforward won't be anymore.
I don't understand the resistance of making it optional. It would benefit everyone.

How many options does the interface have to have before it's considered too much?
For a specific case like this, we only have to choose between keeping the gizmo visible or not.
I don't think it deserves a new option.

> In [D17115](https://archive.blender.org/developer/D17115)#468758, @ThinkingPolygons wrote: > @JulienKaspar Just imagine moving horizontally to align points vertically for example. > > [blender_8iZ5OYoWAS.mp4](https://archive.blender.org/developer/F14232145/blender_8iZ5OYoWAS.mp4) > > Without the visible gizmo axes when transforming, there would be too much guess work/errors because of the distance of the points and also too much click drag and release to see if the gizmo is aligned. > > Might look minor but aligning things using the gizmos axes happens a lot in several situations. I hope you understand what I mean. > So like I said, what you have here would be ok for the multi transform tool. A contrast to the traditional transform gizmos. > Or just make it optional and everybody wins. --- > In [D17115](https://archive.blender.org/developer/D17115)#468829, @mano-wii wrote: > The description shows a very specific and rare usage that is not intended for this gizmo. > This is most expected to be aided by the grid and other forms of precision modeling. > Furthermore, this is only useful in orthographic views and the gizmo is rarely large enough to accurately point to a desired point in the scene. > > I don't think it's worth keeping the gizmo or adding an option to the preferences for such a use. --- > In [D17115](https://archive.blender.org/developer/D17115)#468830, @JulienKaspar wrote: > @ThinkingPolygons Thanks for the example! > An alternative workflow to this could be snapping. As it doesn't require you to zoom out and align the gizmo with what your are seeing. > So you could drag the x axis -> Hold `Ctrl` to snap the center to a vertex or surface. > > | ![image.png](https://archive.blender.org/developer/F14232366/image.png) | ![image.png](https://archive.blender.org/developer/F14232376/image.png) | ![image.png](https://archive.blender.org/developer/F14232373/image.png) > > But I understand how the gizmo can intuitively be used to eyeball alignments instead of using exact snapping. > It's something to think about ... --- > In [D17115](https://archive.blender.org/developer/D17115)#468834, @ThinkingPolygons wrote: > @ germano, that’s not a rare use case at all. > @ kaspar, of course there are several slightly more complicated workarounds for that, but we are losing quality of life here. Things that used to be straightforward won't be anymore. > I don't understand the resistance of making it optional. It would benefit everyone. How many options does the interface have to have before it's considered too much? For a specific case like this, we only have to choose between keeping the gizmo visible or not. I don't think it deserves a new option.

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

I don't use gizmos much myself, so I don't have strong feelings about this either way.
Thinking Polygons example doesn't seem very convincing for keeping axis, there are probably better ways to achieve that.
However, if other users have strong feelings about it maybe instead of another option in the preferences window, we could make it a check box under the Gizmos popover in the 3D View, to avoid more clutter.

I don't use gizmos much myself, so I don't have strong feelings about this either way. Thinking Polygons example doesn't seem very convincing for keeping axis, there are probably better ways to achieve that. However, if other users have strong feelings about it maybe instead of another option in the preferences window, we could make it a check box under the *Gizmos* popover in the 3D View, to avoid more clutter.

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

I'd vote for making it optional.
In other applications, hiding the gizmo is some kind of a modal toggle operation.
So when you start transforming, everything is visible, but during the transformation if you press a modifier key (can be anything) it hides the gizmo... press it once more and it's visible again.
This is the most effective way of implementing this feature, imo...

I'd vote for making it optional. In other applications, hiding the gizmo is some kind of a modal toggle operation. So when you start transforming, everything is visible, but during the transformation if you press a modifier key (can be anything) it hides the gizmo... press it once more and it's visible again. This is the most effective way of implementing this feature, imo...

In #103782#1483240, @DuarteRamos wrote:
Thinking Polygons example doesn't seem very convincing for keeping axis

You said that you don't use gizmos that much yourself, obviously it wouldn't be very convincing to you. But keep in mind that what seems minor to you might be a big deal for others.
And trust me, for eyeballing things there's no better helper than the gizmo, and we're losing it for no valid reason.
I still can't believe this is moving forward without being optional.
This is a serious problem.

> In #103782#1483240, @DuarteRamos wrote: > Thinking Polygons example doesn't seem very convincing for keeping axis You said that you don't use gizmos that much yourself, obviously it wouldn't be very convincing to you. But keep in mind that what seems minor to you might be a big deal for others. And trust me, for eyeballing things there's no better helper than the gizmo, and we're losing it for no valid reason. I still can't believe this is moving forward without being optional. This is a serious problem.
Author
Member

@mano-wii Personally I agree with your points on the gizmo. While the use of the handles as a guide is an nice side product, there are other features that are more worthwhile to use instead.
The upside of simplifying the gizmo is a less blocking and more consistent UI.

There are a bunch of people at the Blender Studio that welcome this change. Animators especially, who use the gizmos a lot and prefer them to not obscure what is being transformed.


The gizmo was permanently visible in recent releases because otherwise it left no visual feedback of where the pivot point & geometry is moved to. This fixed a big issue especially in sculpt mode.
But the new change to make the gizmo more minimal during the operation is much more aligned with how operations are meant to be visualized in Blender (including the rotate gizmo).

I like the idea of a modifier key to hide the gizmos, but all modifier keys are already in use.
So that's not really an option. And assigning another arbitrary key to toggle gizmo visibility is very hidden functionality.

Always making yet another preference is not great. But we must consider that if this change turns out to be unpopular in wide circles.
Once more artists get to test and use it, it's way easier to judge the reactions, so I'd like this patch to land for a release.

@mano-wii Personally I agree with your points on the gizmo. While the use of the handles as a guide is an nice side product, there are other features that are more worthwhile to use instead. The upside of simplifying the gizmo is a less blocking and more consistent UI. There are a bunch of people at the Blender Studio that welcome this change. Animators especially, who use the gizmos a lot and prefer them to not obscure what is being transformed. --- The gizmo was permanently visible in recent releases because otherwise it left no visual feedback of where the pivot point & geometry is moved to. This fixed a big issue especially in sculpt mode. But the new change to make the gizmo more minimal during the operation is much more aligned with how operations are meant to be visualized in Blender (including the rotate gizmo). I like the idea of a modifier key to hide the gizmos, but all modifier keys are already in use. So that's not really an option. And assigning another arbitrary key to toggle gizmo visibility is very hidden functionality. Always making yet another preference is not great. But we must consider that if this change turns out to be unpopular in wide circles. Once more artists get to test and use it, it's way easier to judge the reactions, so I'd like this patch to land for a release.
Author
Member

@mano-wii Also important to note: Your patch implemented this design for the 3D Viewport but not the other editors, like UV Editor and Video Sequencer. So once the patch lands we shouldn't close this design yet.

@mano-wii Also important to note: Your patch implemented this design for the 3D Viewport but not the other editors, like UV Editor and Video Sequencer. So once the patch lands we shouldn't close this design yet.

I think is is important to understand one of the reasons industry standard software has gizmos always turned on.
There is a unobvious but deep differentiation between the way ISS and B3D handle objects.

B3D objects contain a single coordinate system

  • an origin (a true mesh zero, explicit) similar to AutoCAD block's Insertion Point system.

ISS objects contain two coordinate systems

  • an origin (a true mesh zero, implicit - is hidden from user) similar to Autocad insertion point.
  • and pivot point (a dummy coordinate system used for manipulations, explicit) similar to Adobe Photoshop pivot, or Adobe Illustrator pivot but applied in form that is suitable for 3d space ontop of the origin system.

That pivot point has adjustable transforms, but has no physical media - it is a point in the space you can snap anywhere, like 3d cursor (but without displaying 3d cursor) and is transformable during operation.
Handling such kind of a point require displaying gizmo constantly, because there is no other way to depict it in 3d space, for example, for basepoint snapping purposes, since it is a point in the space with no physical media.

In Blender there is no such kind of a paradigm though, and you mostly snap with physical mesh media or specific functionality based on a physical mesh media (like A-key that sets midpoint of a snap or the active element) but the origin system in Blender is often confused with pivot point system (including terminology - in B3D a "pivot" term represents any point you snap with or transform around, while in ISS it represents a dedicated per-object coordinate system with specific behaviour that require permanent gizmo display).
Hope this may clarify some points, this topic in general refers to a bit... deeper system design question than it is usually expected.

I think is is important to understand one of the reasons industry standard software has gizmos always turned on. There is a unobvious but deep differentiation between the way ISS and B3D handle objects. B3D objects contain a single coordinate system - an **origin** (a true mesh zero, explicit) similar to AutoCAD block's **Insertion Point** system. ISS objects contain two coordinate systems - an **origin** (a true mesh zero, implicit - is hidden from user) similar to Autocad insertion point. - and **pivot point** (a dummy coordinate system used for manipulations, explicit) similar to Adobe Photoshop pivot, or Adobe Illustrator pivot but applied in form that is suitable for 3d space ontop of the origin system. That pivot point has adjustable transforms, but has no physical media - it is a point in the space you can snap anywhere, like 3d cursor (but without displaying 3d cursor) and is transformable during operation. Handling such kind of a point require displaying gizmo constantly, because there is no other way to depict it in 3d space, for example, for basepoint snapping purposes, since it is a point in the space with no physical media. In Blender there is no such kind of a paradigm though, and you mostly snap with physical mesh media or specific functionality based on a physical mesh media (like A-key that sets midpoint of a snap or the active element) but the origin *system* in Blender is often confused with pivot point *system* (including terminology - in B3D a "pivot" term represents any point you snap with or transform around, while in ISS it represents a dedicated per-object coordinate system with specific behaviour that require permanent gizmo display). Hope this may clarify some points, this topic in general refers to a bit... deeper system design question than it is usually expected.

@1D_Inc Save it man. There is no need to overcomplicate things with arguments and such.

The only reason this insane change is happening is because you guys are long time blender users therefore not used to work with gizmos like that.
This is something blender didn't do until very recently, and you guys are seeing it as something that is in the way somehow, so you want to restore the old behavior. We go it. But you should also respect the users who asked for this in years.

There has never been a crowd in the industry saying that the gizmo is in the way or cluttering stuff, it's only you guys which are used to work with modal tools who think that.

The way I see it, it doesn't matter how many examples we give or how bad we say this change is, it won't change anything. You guys just want your modal/no gizmo workflow. But this is UX we are talking here. Where is the UI team? And why, why can this be optional, since this is not how a gizmo should work by default?

@JulienKaspar As redwax said, the modifier toggle can be anything, not just shift/ctrl/ or alt, it could be "H" for example. Blender use the H key for hiding stuff, so why not?
Just to give you a perspective, in c4d it's alt+d.

@1D_Inc Save it man. There is no need to overcomplicate things with arguments and such. The only reason this insane change is happening is because you guys are long time blender users therefore not used to work with gizmos like that. This is something blender didn't do until very recently, and you guys are seeing it as something that is in the way somehow, so you want to restore the old behavior. We go it. But you should also respect the users who asked for this in years. There has never been a crowd in the industry saying that the gizmo is in the way or cluttering stuff, it's only you guys which are used to work with modal tools who think that. The way I see it, it doesn't matter how many examples we give or how bad we say this change is, it won't change anything. You guys just want your modal/no gizmo workflow. But this is UX we are talking here. Where is the UI team? And why, why can this be optional, since this is not how a gizmo should work by default? @JulienKaspar As redwax said, the modifier toggle can be anything, not just shift/ctrl/ or alt, it could be "H" for example. Blender use the H key for hiding stuff, so why not? Just to give you a perspective, in c4d it's alt+d.

I want to share my experience about gizmos and modals UX/UI solutions in order to provide some contextual logics, in case if it will be useful.

In early 2000's I learned 3dsmax and the approach provided there (LMB+gizmo using). It was time when 1k vertices per model was a big deal, and such an approach was quite okay.
Then, in 2010's, the industry graphics requirements changed to much more detailed object and dense mesh editing, but the industry standards remained the same, and this exacerbated the systemic problems of its approach, for example, a problem of a selecting mesh elements through gizmo became critical - you always have to be accurate and slow while doing this in order to not to accidentally start gizmo action or switch it off and on all the time.

We tried Blender and it proposed two possible solutions to such problems - RCS (that split mesh/object selecting and gizmo activating actions to different mouse buttons so they never conflicts) and modals (using LCS without gizmo - in verb way), both allowed to bypass such speed limitation.
Since using gizmo during modeling has known general limitations like incompatibility with editing large objects like general plans, we found reasonable to use the second way (LCS+modals) as the most versatile way that fits everything, reducing using gizmos to cases it is beneficial, like animation and other workflows that operate with lots of local transforms and without large/complex selections that pushes gizmos out of viewport bounds.

I just want to say that ISS approach in the way it was designed is much more gizmo-dependent by its nature - if to add gizmo autohiding feature to ISS approach, it will more likely fell apart since it will damage pivot point mechanics.
But it doesnot mean that we in our studio are against gizmos or so, since we also use them, this is why I proposed an option.

I want to share my experience about gizmos and modals UX/UI solutions in order to provide some contextual logics, in case if it will be useful. In early 2000's I learned 3dsmax and the approach provided there (LMB+gizmo using). It was time when 1k vertices per model was a big deal, and such an approach was quite okay. Then, in 2010's, the industry graphics requirements changed to much more detailed object and dense mesh editing, but the industry standards remained the same, and this exacerbated the systemic problems of its approach, for example, a problem of a selecting mesh elements through gizmo became critical - you always have to be accurate and slow while doing this in order to not to accidentally start gizmo action or switch it off and on all the time. We tried Blender and it proposed two possible solutions to such problems - RCS (that split mesh/object selecting and gizmo activating actions to different mouse buttons so they never conflicts) and modals (using LCS without gizmo - in verb way), both allowed to bypass such speed limitation. Since using gizmo during modeling has known general limitations like incompatibility with editing large objects like general plans, we found reasonable to use the second way (LCS+modals) as the most versatile way that fits everything, reducing using gizmos to cases it is beneficial, like animation and other workflows that operate with lots of local transforms and without large/complex selections that pushes gizmos out of viewport bounds. I just want to say that ISS approach in the way it was designed is much more gizmo-dependent by its nature - if to add gizmo autohiding feature to ISS approach, it will more likely fell apart since it will damage pivot point mechanics. But it doesnot mean that we in our studio are against gizmos or so, since we also use them, this is why I proposed an option.
Author
Member

@torrent-1 Examples and showing typical use cases are crucial actually. Pros and cons are constantly being weighted.
The negative response has set the patch into moment of pause. Only the bug fixes that were part of the patch have been committed for now.

@torrent-1 Examples and showing typical use cases are crucial actually. Pros and cons are constantly being weighted. The negative response has set the patch into moment of pause. Only the bug fixes that were part of the patch have been committed for now.

To mention, B3D is not the only software that allowed to hide gizmos during operation.
For example, substance 3d modeller also use such a strategy, this allow to check the resulting composition during modeling while having visually complex gizmos.

https://youtu.be/MDwzygN-nF0

Also, as far as I remember, alt+d in C4D is about temporal hiding gizmos before transform (similar to 3dsmax X key in early versions, to bypass gizmo's selection blocking), not during actial transform.

https://youtu.be/7iD61p3fg8o

To mention, B3D is not the only software that allowed to hide gizmos during operation. For example, substance 3d modeller also use such a strategy, this allow to check the resulting composition during modeling while having visually complex gizmos. https://youtu.be/MDwzygN-nF0 Also, as far as I remember, alt+d in C4D is about temporal hiding gizmos before transform (similar to 3dsmax X key in early versions, to bypass gizmo's selection blocking), not during actial transform. https://youtu.be/7iD61p3fg8o
Philipp Oeser removed the
Interest
Modeling
label 2023-02-09 15:27:05 +01:00

The design was implemented in 97c05aa288.
So closing.

Thanks for the feedback.

The design was implemented in 97c05aa288f. So closing. Thanks for the feedback.
Blender Bot added
Status
Archived
and removed
Status
Confirmed
labels 2023-04-17 15:38:55 +02:00

The task is closed, but I want to clarify my point about difference between B3D and ISS.

I meaned, unlike the other software, you can use Blender with full gizmos, you can use Blender with no gizmos at all, you can have partial gizmos, you can have gizmos autohiding, and Blender will stay fully functional for any of those cases, because of a nifty system design which is incredibly permissive.

The task is closed, but I want to clarify my point about difference between B3D and ISS. I meaned, unlike the other software, you can use Blender with full gizmos, you can use Blender with no gizmos at all, you can have partial gizmos, you can have gizmos autohiding, and Blender will stay fully functional for any of those cases, because of a nifty system design which is incredibly permissive.
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
Interest: X11
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
9 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#103782
No description provided.