Thanks for catching this! Is there a way that you can modify the existing mouse drag tests or add a new one to check for this? Those tests are a bit tricky to write / understand since they spoof mouse movements, so if there isn't an easy way to do that I think I would be fine with skipping it.

Thanks for catching this! Is there a way that you can modify the existing mouse drag tests or add a new one to check for this? Those tests are a bit tricky to write / understand since they spoof mouse movements, so if there isn't an easy way to do that I think I would be fine with skipping it.

I suppose I could try - but which existing tests did you have in mind? It seems most tests are for roll=0, with the exception of test_bar3d_shaded(), test_shared_view() and test_format_coord(), but these are clearly for other purposes than roll specifically.
We might add a variation on test_axes3d_rotated() with non-zero roll, for starters; and turn test_pan() into a test_rotate() for the mouse, since the rotation doesn't have much test coverage, apparently. And then add a test_rotate_with_roll(). Does that sound like a plan? (Or does it sound like it needs a separate PR? Please advise...)

I was thinking about test_pan and test_toolbar_zoom_pan, but it looks like we don't actually have an equivalent test for rotating the view. If you want to take a shot at writing a similar test for rotating go for it, but it might be tricky so if you're not comfortable with that then we can merge as-is and I'll open an issue to add those tests.

https://github.com/matplotlib/matplotlib/blob/main/lib/mpl_toolkits/mplot3d/tests/test_axes3d.py#L1769-L1880

I'll give it a try and let you know, it might take me a day or two

[...] We hope to see more of you, and contributions are always welcome!

Well, now that we're at it...
Part of your commit 'Add ability to roll the camera in 3D plots' (#21426, 3 year ago...) reads:
- Make elev, azim, roll ordering consistent everywhere
This sounds like a good idea to me. However, I am puzzled by your choice of ordering (elev, azim): it is just the opposite of the matlab convention; and when I google:

• "azimuth, elevation" -> 291 000 results
• "elevation, azimuth"-> 41 500 results

And similarly:

• "azimuth, elevation, roll" -> 1380
• "elevation, azimuth, roll" -> 188

That is to say, the ordering you chose is not the common one. And if you consider that searching for both yields

• "azimuth, elevation" and "elevation, azimuth" -> 37 500 results

(some links are non-committal), then it becomes clear that the elevation, azimuth order is really a minority position: (41-37)/(291-37) < 2%.
Moreover, the ordering with elevation first does not correspond to the order in which the 3 rotations take place.

Should we raise an issue to change it?
(You had the good foresight to use named parameters, so it is not a completely breaking change...)

I had a comment and it was mostly wrong when I actually went back to look, so ignore that email. I forget the reasoning behind changing the argument order, but I believe it’s to match the order in which the rotations are applied.

I’d be hesitant to change it again. Matching Matlab convention is nice, but not an actual goal of the matplotlib library. The kwargs are clear and unambiguous as-is, and we try to minimize API changes per this policy: https://matplotlib.org/devdocs/devel/api_changes.html

I had a comment and it was mostly wrong when I actually went back to look, so ignore that email. I forget the reasoning behind changing the argument order, but I believe it’s to match the order in which the rotations are applied.

I’d be hesitant to change it again. Matching Matlab convention is nice, but not an actual goal of the matplotlib library. The kwargs are clear and unambiguous as-is, and we try to minimize API changes per this policy: https://matplotlib.org/devdocs/devel/api_changes.html

I understand the hesitation, and I don't particularly care about what Matlab's convention is either. But I do care that all the rest of the world appears to do something else than what matplotlib does at the moment. And the matplotlib order emphatically does not match the order in which the rotations are applied: that is azim, elev, roll.
So now the reasons to change it are 3 to 1 (doing things properly vs. eternal compatibility with the horrors of the past). There is a clear benefit to changing the order. Arguably it could be worth the effort of adapting existing code, as per https://matplotlib.org/devdocs/devel/api_changes.html (especially in view of the fact that the effort might be limited, with the named parameters). I thought it might make sense?

Elevation and azimuth are applied at the same time, in effect neither comes before the other.

https://github.com/matplotlib/matplotlib/blob/main/lib/mpl_toolkits/mplot3d/axes3d.py#L1220-L1222

Thinking about it more, I think you’re more right about the rotation order if this is conceptualized as Euler angles. If thinking about extrinsic rotations, then the rotation order is roll, elev, then azim. If thinking about intrinsic rotations then the rotation order is azim, elev, then roll. The definitions in the docs are still unambiguous so I still think this is fairly marginal to make a change of API, but maybe @oscargus can weigh in.

Thinking about it more, I think you’re more right about the rotation order if this is conceptualized as Euler angles.

Well actually, to be precise, mplot3d's azim, elev, roll are a kind of Tait-Bryan angles, not classic Euler angles (there exist 12 kinds of each, not counting the signs...)

If thinking about extrinsic rotations, then the rotation order is roll, elev, then azim. If thinking about intrinsic rotations then the rotation order is azim, elev, then roll.

Ah, yes, now we're talking!
The corresponding quaternion (for the intrinsic rotation) is
q = exp((+roll/2)*e_x)*exp((+elev/2)*e_y)*exp((-azim/2)*e_z)
i.e., Tait-Bryan angles, -z,y',x".

The definitions in the docs are still unambiguous so I still think this is fairly marginal to make a change of API, but maybe @oscargus can weigh in.

Ah yes. So perhaps it is time to open a separate Issue and close this PR ;)