3D Controls

This page is devoted to controls that a programmer can provide to allow a user to select a viewpoint for a 3D image. Rotations do not combine like numbers or directions do - the order of the computations matters. For example, walking three miles North and then two miles East will put you at the same location as walking two miles East and then three miles North. On the other hand, pitching thirty degrees and then yawing twenty degrees will not leave you at the same orientation as yawing twenty degrees and then pitching thirty degrees.

So, there isn't a single obvious way of entering orientations, and therefore various different controls with different pluses and minuses have been invented; this page aims to describe them.

GameDev.net is a great source for information on 3D controls and graphics. Another set of well written articles can be found at Delphi3d.net.

You can also download my Windows Control3D program. It includes Delphi source code as well as a compiled program. To download this file, shift+click here. This program demonstrates the Euler Angles, Vector and Roll and ArcBall controls. I wrote this program while trying to decide which control to add into my MRIcro software. So it is perhaps ironic that the control I finally decided to use (Elevation and Azimuth) is not included. However, Earl F. Glynn's 3D Lab is a perfect demonstration of the Elevation and Azimuth control (which also includes Delphi source).

Euler Angles (Yaw, Pitch and Roll)

Most people expect yaw, pitch and roll to be the perfect way to describe 3D rotations. However, these parameters influence each other. Therefore the order of these computations can create a problem. So if you shift a viewpoint by a YPR of 20,30,-10 degrees, you can not get back to the starting angle by simply computing the YPR of -20,-30,10 degrees (you would have to compute in the order RPY). Jed Margolin has introduced a nice way to visualise this problem: "When a series of rotations are done together around two or three axes, the order of rotation makes a difference. Visualize an airplane suspended in air, wings straight and level, nose pointed North. Roll 90 degrees clockwise, then pitch 90 degrees 'up'. The nose will be pointing East. Now we will start over and reverse the order of rotation. Start from straight and level, pointing North. Pitch up 90 degrees, then Roll 90 degrees clockwise, The nose will now be pointing straight up, where 'up' is referenced to the ground. If you have trouble visualizing these motions, just pretend your hand is the airplane."

Another problem is known as Gimbal Lock: when one of the first rotations is done to 90 degrees, it shifts the frame of reference for the following angles. Euler angles will appear intuitive if you have the user enter a rotation one dimension at a time and then update their viewpoint. However, the user may become confused when they try to return to their original viewpoint. This 3DFX tutorial shows you how to convert YPR into standard matrices that you can use to transform images. GameDev.net also has a nice tutorial and sample C program describing gimbal lock.

  • Users are familiar with yaw, pitch and roll.
  • Limits user: some viewpoints are impossible (e.g. from the user's viewpoint, the object can only be rolled when the elevation is set to the poles).
  • Unable to specify all viewpoints (gimbal lock).
  • Unintuitive when gimbal lock occurs.

Vector and Roll

This method was popularized by OpenGL, which uses it in its GLRotate[angle,vector] function. The user specifies a Roll Angle (0..360 degrees) and a unit vector (the X,Y,Z coordinates of a point on the surface of the unit sphere). The roll angle specifies how much the object should be rotated around the axis from the centre of the sphere to the point specified by the vector. This method is described in the latter half of this 3DFX tutorial.

While this description is useful for programmers, it generates a frustrating and unintuitive interface for the user. It is hard to juggle 3 parameters that interact with each other. One solution is to have the user specify a vector by clicking on a picture of a globe and then have them enter a roll angle. However, people are not used to thinking about the roll angle of an object.

  • Any viewpoint can be described.
  • The vector is specified by 4 parameters, with 3 that interact with each other, so the user can not precisely enter these into software to show the identical viewpoint of different objects.
  • Unituitive.
ArcBall / Quaternions

Quaternion's allow you to describe a 3D viewpoint with 4 parameters. Like the vector and roll, this technique allows you to view an object from any possible viewpoint. Perhaps the single most powerful implementation of quaternions for viewing 3D objects is Ken Shoemake's ArcBall controller (1994). Sample ArcBall controllers are available in Delphi, Visual Basic and Shoemake's original C code. This controller allows the user to rotate the object with the mouse. You simply click somewhere on the surface of the sphere and rotate the ball sphere around. For technical details about quaternions, see GameDev.Net. This is probably the best general purpose 3D control.

  • ArcBall Controller is intuitive for the user.
  • Any viewpoint can be described.
  • The viewpoint is specified by 4 parameters that interact with each other, so the user can not precisely enter these into software to show the identical viewpoint of different objects.
Elevation and Azimuth

You can specify a viewpoint based on the elevation and azimuth of the viewer. For example, consider the brain on the left, the user could select to view the image from an azimuth of 20 degrees, from an elevation of 30 degrees (i.e. to the right and from slightly above). This specifies the vector show in green. This technique is illustrated at Earl F. Glynn's 3D Lab. I also use this technique for my MRIcro software.

Advanced comment: the two independent parameters of elevation and azimuth together define a dependent unit vector (i.e. any point on the sphere's surface is a unit vector if the radius of the sphere is 1). As the pictures suggest, the "Vector and Roll" and "Elevation and Azimuth" controls are closely related - with the Vector and Roll control adding a roll component to allow any viewpoint. However, it is much easier to conceptually think of Elevation and Azimuth as controlling the viewer's position with respect to the object and Vector and Roll as an object centered frame of refence.

  • Intuitive for the user.
  • Only requires two parameters (easy to remember and set the same viewpoint for different images).
  • The parameters do not interact with each other.
  • Limits user: some viewpoints are impossible (e.g. from the user's viewpoint, the object can only be rolled when the elevation is set to the poles). However, this failure is intuitive to the user.