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:

Blender 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.


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:

Click and drag to explore this system:

Your browser doesn't appear to support the <canvas> element.

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.


Let's modify our turntable system with a minor change:

Your browser doesn't appear to support the <canvas> element.

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 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:

Your browser doesn't appear to support the <canvas> element.

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.


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

My casual recommendation is as follows:

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.