You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #28290 introduced more natural 3D rotation with the mouse. It uses a variation on Ken Shoemake's Arcball (it doesn't spin at double the mouse speed); however, this variation spoils a nice feature of the original Arcball (as Scott Shambaugh pointed out): if you move the mouse back the original point on the screen, this would return the view to the original view.
It would be desirable to be able to choose what kind of mouse rotation style one wants (Ken Shoemake's original Arcball, or the not-the-double-speed variation of the PR, or Holroyd's arcball, or a Trackball, or indeed the original matplotlib style which does not control roll, much like in matlab).
Proposed solution
Make the mouse rotation style selectable using rcParams. Perhaps axes3d.mouserotation ?
I'm not an expert in this topic, so do we really need all those impementations? I assume 99% of users just want that "it works", which means one good rotation style should be enough.
I'm not an expert in this topic, so do we really need all those imp[l]ementations? I assume 99% of users just want that "it works", which means one good rotation style should be enough.
I was originally of this opinion too - see #28290 (comment).
But I can see Scott's point; and there are legitimate trade-offs between various mouse rotation styles. With a few lines extra code we could accommodate the various preferences.
As for the 99% of users, they will have the default style and it will "just work" for them.
this variation spoils a nice feature of the original Arcball (as Scott Shambaugh pointed out): if you move the mouse back the original point on the screen, this would return the view to the original view
This is the main thing I'm hoping to resolve, but I can see the different rotation modes being useful for different input devices / accessibility concerns.
This is the main thing I'm hoping to resolve, but I can see the different rotation modes being useful for different input devices / accessibility concerns.
I have a PR in the works for it, almost ready, but I'm waiting for the merge of PR #28395, I'd prefer to finish one PR before starting another...
Could you take a look at it, or ask someone else to do so?
I would go as far as to argue that rolling the axes in 3d is an anti-feature in most cases. The gain in flexibility makes it harder to control and achieve the desired view with mouse interactions. This is especially the case when viewing data that is plotted with z-direction being physically meaningful is some way (like a 3d histogram or wireframe with size in the z-direction measuring some quantity). From a visualisation perspective, rotating in azimuth is very useful here, while rolling is actually just annoying. Therefore I think it's essential that we are able to restore the old rotation behaviour on user request. I was envisioning something like holding down CNTRL key to toggle the rotation behaviour.
I would go as far as to argue that rolling the axes in 3d is an anti-feature in most cases. [...] Therefore I think it's essential that we are able to restore the old rotation behaviour on user request.
I take it that you are very happy with the change proposed in this Issue, then?
I was envisioning something like holding down CNTRL key to toggle the rotation behaviour.
This proposal I find puzzling - surely a CNTRL key does not mesh well with the 'principle of least surprise'? (And you want to hold it down? Or you want to toggle?)
Would a selection on the toolbar be better?
Could it be that what you really want is to constrain the roll to zero to keep the z axis parallel to the edge of the figure? That is a separate issue from having the rotation respond naturally to the mouse (i.e., move mouse to the left/right/up/down -> tilt figure to the left/right/up/down, consistently). Perhaps it deserves raising a separate Issue? (Feel free...)
IMHO a rcParam for the rotation mode should be good enough (if we need multiple options). You can set this globally in your matplotlibrc, or you can set it before showing the figure. You'll hardly need to toggle different modes live.
I was surprised by trackball control after updating matplotlib. Despite what was argued here and in #28290, trackball control doesn't feel strictly superior to the old azimuth/elevation control scheme. While it does allow moving the plot into strictly more orientations, it comes at the cost of being less intuitive in the case where controlling roll is not desired (as @astromancer also mentioned). For what it's worth, I think cases where locked roll is sufficient are common enough and the difficlty of controlling a trackball is high enough, that the trackball is only desirable in specific circumstances.
For what it's worth, along with MATLAB, tools such as Geogebra 3D or Desmos 3D also have azimuth/elevation controls only.
You'll hardly need to toggle different modes live.
Not between trackball/sphere/arcball modes; however, the choice of locking/unlocking roll does depend on the plot being viewed. I think it would have made more sense to make the choice between trackball/sphere/arcball a configuration option, as this is just user preference. However, locking and unlocking roll would have been useful live, either with a control key (I don't think this is any more "surprising" than any other choice of mouse or keyboard controls), or with an option in the toolbar.
Hi @just-max, I can understand your reasons for wanting a way to lock/unlock the roll live, via the toolbar or a control key, it makes some sense. If nobody is outright opposed to it, I'll consider trying to make a patch to do something sensible (but don't count on it overnight...)
Activity
timhoffm commentedon Jun 17, 2024
I'm not an expert in this topic, so do we really need all those impementations? I assume 99% of users just want that "it works", which means one good rotation style should be enough.
MischaMegens2 commentedon Jun 17, 2024
I was originally of this opinion too - see #28290 (comment).
But I can see Scott's point; and there are legitimate trade-offs between various mouse rotation styles. With a few lines extra code we could accommodate the various preferences.
As for the 99% of users, they will have the default style and it will "just work" for them.
scottshambaugh commentedon Jun 25, 2024
This is the main thing I'm hoping to resolve, but I can see the different rotation modes being useful for different input devices / accessibility concerns.
MischaMegens2 commentedon Jun 26, 2024
I have a PR in the works for it, almost ready, but I'm waiting for the merge of PR #28395, I'd prefer to finish one PR before starting another...
Could you take a look at it, or ask someone else to do so?
astromancer commentedon Jul 2, 2024
I would go as far as to argue that rolling the axes in 3d is an anti-feature in most cases. The gain in flexibility makes it harder to control and achieve the desired view with mouse interactions. This is especially the case when viewing data that is plotted with z-direction being physically meaningful is some way (like a 3d histogram or wireframe with size in the z-direction measuring some quantity). From a visualisation perspective, rotating in azimuth is very useful here, while rolling is actually just annoying. Therefore I think it's essential that we are able to restore the old rotation behaviour on user request. I was envisioning something like holding down CNTRL key to toggle the rotation behaviour.
MischaMegens2 commentedon Jul 2, 2024
I take it that you are very happy with the change proposed in this Issue, then?
This proposal I find puzzling - surely a CNTRL key does not mesh well with the 'principle of least surprise'? (And you want to hold it down? Or you want to toggle?)
Would a selection on the toolbar be better?
Could it be that what you really want is to constrain the roll to zero to keep the z axis parallel to the edge of the figure? That is a separate issue from having the rotation respond naturally to the mouse (i.e., move mouse to the left/right/up/down -> tilt figure to the left/right/up/down, consistently). Perhaps it deserves raising a separate Issue? (Feel free...)
timhoffm commentedon Jul 3, 2024
IMHO a rcParam for the rotation mode should be good enough (if we need multiple options). You can set this globally in your matplotlibrc, or you can set it before showing the figure. You'll hardly need to toggle different modes live.
This makes implementation much simpler.
Make mplot3d mouse rotation style adjustable
just-max commentedon Aug 17, 2025
I was surprised by trackball control after updating matplotlib. Despite what was argued here and in #28290, trackball control doesn't feel strictly superior to the old azimuth/elevation control scheme. While it does allow moving the plot into strictly more orientations, it comes at the cost of being less intuitive in the case where controlling roll is not desired (as @astromancer also mentioned). For what it's worth, I think cases where locked roll is sufficient are common enough and the difficlty of controlling a trackball is high enough, that the trackball is only desirable in specific circumstances.
For what it's worth, along with MATLAB, tools such as Geogebra 3D or Desmos 3D also have azimuth/elevation controls only.
Not between trackball/sphere/arcball modes; however, the choice of locking/unlocking roll does depend on the plot being viewed. I think it would have made more sense to make the choice between trackball/sphere/arcball a configuration option, as this is just user preference. However, locking and unlocking roll would have been useful live, either with a control key (I don't think this is any more "surprising" than any other choice of mouse or keyboard controls), or with an option in the toolbar.
MischaMegens2 commentedon Aug 18, 2025
Hi @just-max, I can understand your reasons for wanting a way to lock/unlock the roll live, via the toolbar or a control key, it makes some sense. If nobody is outright opposed to it, I'll consider trying to make a patch to do something sensible (but don't count on it overnight...)