Are there specific use cases that you see for the other three roll control methods? I think it would make more sense to provide users just the "best" options rather than all the possible options. Eliminates some sources of potential confusion, and less code reduces the maintenance burden.

Well I imagine that different people have different preferences, or they already are used to something specific. Why force a particular approach on them, when it is easy enough to provide a choice? The maintenance burden is relatively minor, eliminating all the trackballs-but-one would only save a handful of lines.

@scottshambaugh - an updated PR is waiting for your review

Why force a particular approach on them, when it is easy enough to provide a choice? The maintenance burden is relatively minor, eliminating all the trackballs-but-one would only save a handful of lines.

I don't feel too strongly about this, and it wouldn't really hurt. I just don't immediately see any uses where the alternate rotation methods with roll control are valuable. Would appreciate if another maintainer could weigh in with their opinion.

I think we should definitely be very choosey about the default though - can keep talking about that in the comment chain higher up.

Maintenance burden is only on side, and may not be too bad here. But options and choice are also mental load, both for users and maintainers. It makes a difference whether you have to understand two options or four. If there are good reasons/use cases for all the options, we should take them. If they are just added because we've found more mathematical ways to describe rotations, leave them out.

I'll make a proposal then: 1) we'll make the width of the transition region in@scottshambaugh 's proposed arcball variant adjustable, rather thanad hoc have it fixed at 60°. In this way, you can have either a) just a true arc ball (with zero transition width but and abrupt edge) or b) a smoothed edge one. The need for the funny hyperbolic Holroyd arcball then all but disappears, so 2) we drop that. This leaves us with 4 variants, each with a clear use case/reason for their existence:

• the traditional 'azel', with its preferred axis (and no roll control)
• 'trackball', with uniform response (good), and without an edge (also good); but still not much control over roll (some control, but only if you know the trick)
• 'arcball', a virtual trackball, with easier control over roll (good), but a noticeable edge/non-uniformity (the price), and the 'path memory' (which you may actually like, since it is 'natural' in a way - as in the trackball, or you may dislike, since it complicates what's happening)
• 'Shoemake', also with easy control over roll, and orientation independent of the path the mouse took (which you might value highly, or find unnatural), at the price of a disconnect between turning of the trackball and movement of the mouse along the rim of the trackball (the double angle thing)

And then anyone can pick their poison, fair is fair.

I can see how the "single speed" roll that tracks the mouse can be a useful property. I think that's a good argument for including it as an option! So I'm on board with your idea to have the four options of 'azel', 'trackball', 'arcball', and 'matplotlib' (Shoemake-like with the fillet, whatever we call it), and scrapping 'Holroyd'/'Bell'.

Unfortunately it is mutually exclusive with the path independence property. With our differing opinions on which is more intuitive to use (for what it's worth,Usability Analysis of 3D Rotation Techniques found people equally fast with trackball & shoemake), how to rank them? We need a default which will make life easiest for the 99% of users who won't touch this setting.

I think the strongest argument is that path independence allows for easily "undoing" a rotation that the user didn't intend, which fulfills theUX Principle of Forgiveness. It's very easy to otherwise get "lost" in rotation space, especially if your mouse accidentally leaves the axes box and reenters it elsewhere.

I also like that you can reach the full sphere of orientations with a single-click, rather than just the front hemisphere as you can with arcball. But that's a personal preference.

Edit: I did also happen to see this thread on twitter pop up today about several people complaining about 3D precession :)https://x.com/rms80/status/1843338041957687578

@scottshambaugh What is your current opinion on this vs.#28823?

If the only sticking points here are default/docstring here then in discussing with@tacaswell and@QuLogic, we are comfortable sorting those out in follow up PRs during the RC (Though an issue to track that follow up would be good).

We have also said that we are comfortable with you doing a one review merge on this topic if you are satisfied.

@MischaMegens2 thank you for those updates, I think this is good to go now! Appreciate the collaboration polishing this up. I think I'm going to try to write up a blog post on the new methods, since it doesn't look like there's been any innovation in these control methods over the past 20 years and I think we came up with some good ideas.

@ksunden I think this is good to merge now. If there's time pressure to get rc1 out, then I'm happy to solo-merge, but want to give other people a last chance to check it out. We can always refine docstrings down the line. I won't be able to make the weekly meeting today - maybe float it for a last look?

@MischaMegens2 thank you for those updates, I think this is good to go now! Appreciate the collaboration polishing this up.

Thank you too! Itdoes get considerably better with two pairs of eyes, looking at it :)

Unfortunately it is mutually exclusive with the path independence property. With our differing opinions on which is more intuitive to use, how to rank them? We need a default which will make life easiest for the 99% of users who won't touch this setting.

I think the safest bet istrackball, it is easiest to understand, no surprises, it works the same in the middle and at the edge of the screen, no guesswork as to what it does.
As for me personally, I kind of likearcball. Hopefully, more advanced users already familiar with other mouse rotation methods will be able to find the option, once they start looking for it. (Your blog entry might help too!)
The question is then more: "Who do we cater to?" (If 99% of our users are already in the latter group, thensphere orarcball makes sense.)

@scottshambaugh: There were still a few glitches in the view_angles.rst documentation, I've tried to fix them; and I took the liberty to set the default style totrackball - but if you really think that that is a terrible idea then we can revert that...

Ireally don't think having a default with hysteresis is a good user experience. If you think arcball is too confusing for users then I would rather keep the default as azel.

Ireally don't think having a default with hysteresis is a good user experience.

All right, then let's keep the arcball, it is a nice idea, and it is better not to underestimate our users ;)
I reverted the style change.
Now there is all the more reason for that blog then, what are your plans?

Remaining test failures are unrelated to this change, all comments have been resolved,@ksunden has given the go-ahead for a solo-review merge in the interest of getting this into 3.10, and I pinged the devs inthe gitter channel last week to make sure people had a chance to review. With all that resolved I am merging this in - thanks again@MischaMegens2 for the work that went into the new 3d view control methods!

I started putting together a skeleton of a blog post but it's going to take some time to flesh out. Will definitely let you know when it's done.

@MischaMegens2 I finished up my post doing a deep dive into virtual trackballs, curious to hear your thoughts!
https://theshamblog.com/virtual-trackballs-a-taxonomy-and-new-method/