Introduction
When interacting with 3D models on a 2D screen, users expect to be able to spin the model around and inspect it from all angles.
This turns out to be a fascinating HCI problem, with a large corpus of research into different system designs.
Compare the rotation behavior in Blender and Meshlab:
There's a clear difference, but it's not obvious how to put it into words or code.
Let's walk through a few common rotation systems, looking at what they get right and wrong.
Turntable
Let's start with what's known as "turntable" rotation. All of the systems we'll be exploring are mouse-based; when you click and drag, the angle changes:
- Left and right rotate around the viewpoint's global z axis.
- Up and down rotate around the viewpoint's local x axis.
Click and drag to explore this system:
There's one obvious flaw with this system: it's impossible to see the model from arbitrary angles, because the model's Z axis is always pointing up and down on the screen.
Tumbler
Let's modify our turntable system with a minor change:
- Left and right rotate around the viewpoint's local y axis.
- Up and down rotate around the viewpoint's local x axis.
This system allows rotation to an arbitrary angle, but feels very unintuitive: users end up "tumbling" the model by moving the mouse in small circles, walking towards the desired target position.
There's another, more subtle critique of this system: it lacks path independence. This means that if you start and end a drag with your mouse at a particular location, the rotation will depend on the path that your mouse took.
Trackball
Trackball rotation refers to a whole family of systems, described in detail in Virtual Trackballs Revisited.
As hinted by its name, we project a sphere (the "ball") onto the model. When the user clicks, we "grab" that point on the sphere. As the mouse is dragged, we derive the rotation that puts the grabbed point onto the new mouse position.
Try it out below:
As you may notice when playing with this model, you can only rotate the model a maximum of 180º. If you keep dragging, rotation doesn't continue indefinitely.
There's a bit of subtlety in how exactly screen coordinates are mapped to the virtual trackball. Here, I'm using Holroyd's strategy: instead of a pure sphere, we blend between a sphere and a hyperbola. This eliminates discontinuities at the sphere's radius.
For more details and alternate mappings, see the paper linked above.
Summary
What's the right rotation system for your 3D application?
The table below summarizes the desirable features that we've identified.
| Arbitrary rotation | Path independent | Unlimited rotation | |
| Turntable | ✘ | ✔ | ✔ |
| Tumbler | ✔ | ✘ | ✔ |
| Trackball | ✔ | ✔ | ✘ |
My casual recommendation is as follows:
- If the model has an associated real-world axis, then use turntable
- If there's not a fixed, real-world axis, use trackball rotation
- The only excuse for tumbler rotation is not knowing any better
Interestingly, we mix turntable and trackball rotation in Preform, Formlab's 3D printer host software. Can you spot the difference?
Rotation of the viewport uses turntable rotation, because the 3D space is mimicking the printer's build volume; model rotation uses an arcball (with explicit UI hints) because of the analogy to grabbing the model's surface.