Tom Leathrum is Associate Professor of Mathematics at Jacksonville State University.

This, the second article in the series (see link at left for the first article), continues my intent to encourage working college math instructors to write their own applets, and to share their results with other developers, by providing mathematical incentives for learning how to write applets. In this article I look at some of the interesting mathematics underlying basic three-dimensional graphics.

Published April, 2002

© 2002 by Tom Leathrum

The applet shown here displays a surface in transparent wireframe form. The surface is a hyperbolic paraboloid, given by the equation z = (x²  - y²)/8, and with axis bounds -10 to 10 for all three axes. The graph can be rotated in the applet by clicking and dragging the mouse on the graph.

Note the effects of left-right and up-down mouse-dragging motions on the graph, and how the rotations affect the coordinate axes. In particular, while there seems to be much freedom in the motions of the x- and y-axes, the motions of the z-axis are much more constrained: It can be "rolled" forward or backward (relative to the viewer), but it cannot be rotated clockwise or counterclockwise. Why not? This question is the puzzle that motivates this article.

The answer comes from the mathematics needed to establish reasonable three-dimensional graphics, and in particular the projection of three dimensions to two (for the purpose of displaying on the computer screen). Certain compromises must be made to achieve natural-seeming mouse click-and-drag rotations in the applet.

As a warm-up, consider the mathematics behind basic two-dimensional graphics. The applet shown here allows movement of the red dot by clicking and dragging it with the mouse. As the dot is moved, its position is given both in graph coordinates (as indicated by the axes shown) and in pixel position (which is how the computer represents position within the applet). The initial position of the dot is at the coordinate origin, where the shown axes intersect.

The formulas for the transformations between graph coordinates and pixel position are fairly straightforward. For the formulas given below, the graph coordinates of the red dot are given by the pair of values (x,y), its pixel position by the pair of integers (x_pix,y_pix). The pixel height and width of the applet's graph panel are given by the integer values ht and wd, respectively -- in the applet, the height and width are both 200 pixels. The x-axis shows coordinate values in the range from x_min to x_max (in the applet, -5 to 5), and the y-axis shows values from y_min to y_max (also -5 to 5 in the applet). The scaling factors given first provide coefficients for the affine transformation.
 

Keep in mind: For pixel position, the point (x_pix,y_pix) = (0,0) is in the upper left hand corner of the graph. Positive values of x_pix correspond to positions to the right of this point, and positive values of y_pix give positions below this point.

For graphing a surface in space, as in the first applet, the fundamental problem is one of presenting the three-dimensional object in a two-dimensional image (on the computer screen). Given a point \((x_3,y_3,z_3)\) in space, this amounts to finding a corresponding point \((x_2,y_2)\) in the plane, with suitable coordinate systems. Once \((x_2,y_2)\) has been found, it can be converted to pixel position by the transformations in part 3. To simplify the computations, it is reasonable to require that this projection have the property that the point \((0,0,0)\) in space projects to the point \((0,0)\) in the plane.

So how is this projection accomplished? Note that the word "projection" here is being used in a sense somewhat different from the linear algebra definition of a projection, of one vector onto another. The two notions of projection are closely related, though -- in fact, the linear algebra projection will be used to compute the projection from three dimensions to two. To see this, it is important to see first the key vector used in the projection: The view vector is the unit vector in space pointing from the origin of the three-dimensional coordinate system directly perpendicular to the computer screen. This vector determines the direction from which the viewer sees the object in space being presented on the screen. The applet below allows the same graph rotations as the first three-dimensional graphing applet -- which have the effect of changing the view vector -- it also includes a shown vector, indicated by a blue arrow. (In the initial default settings, this arrow is concealed by the axes -- rotate the graph a bit to reveal it.) The green lines and arcs in the applet show how two angles can be used to specify the shown vector.

The angles used to specify the shown vector (or any unit vector in space) are the angles \(\theta\), measured counterclockwise from the positive \(x\)-axis in the \(xy\)-plane (denoted "a" in the applet), and \(\phi\), measured down from the \(z\)-axis (denoted "b"), as used in spherical coordinates. These angles \(a\) and \(b\) for the view vector will be called here the view angles. The "Up" and "Down" buttons transfer the angles from one vector to the other: "Up" from the shown vector to the view vector, not changing the shown vector but rotating the graph so that the shown vector is perpendicular to the computer screen; or "Down" from view vector to shown vector, not rotating the graph but changing the shown vector so that it is perpendicular to the computer screen (the same direction as the view vector). The "Reset to Default" button sets all angles to 45 degrees, the initial default settings.

Notice the effects of mouse motions (when clicking and dragging on the graph for graph rotations) on the view angles: Horizontal mouse motions affect only \(a\), and vertical mouse motions affect only \(b\). This is a natural way to establish the rotations from mouse motions, but further reinforces the puzzle of this article: If every view vector can be described using these two view angles, and the mouse position can be used to change both angles, why is the motion of the z-axis so restricted?

The procedure for carrying out the projection from three dimensions to two begins by expressing the view vector as a unit vector \(u\) depending on the two view angles \(a\) and \(b\) by the formula

Now, for a point \(P = (x_3,y_3,z_3)\) in space, take the vector \(v\) from the origin to \(P\), i.e. \(v = <x_3,y_3,z_3>\). Since \(u\) is a unit vector, the (linear algebra) projection of \(v\) onto \(u\) can be computed as proj\(_u v =(u \cdot v)u\) (the dot product of \(u\) and \(v\), scalar product with \(u\)). The vector given by \(v -\)proj\(_u v\) lies in the plane through the origin and perpendicular to \(u\). The head point \(Q\) of this vector has the useful property that the line through \(P\) and \(Q\) is perpendicular to that same plane (if \(P\) is not in the plane). Since the plane perpendicular to \(u\) is also parallel to the plane of the computer screen, this point \(Q\) can be interpreted as a point in a coordinate system on the computer screen.

The astute reader may realize that the key to the puzzle has just been mentioned: The plane perpendicular to the view vector \(u\) must have a coordinate system in order for \(Q\) to be interpreted in it. Even with the assumptions that the coordinate system in the plane will be orthonormal and right-handed, there is still the matter of rotation -- that is, rotation of the plane around the view vector \(u\). The view angles \(a\) and \(b\) uniquely determine the view vector \(u\), but say nothing about rotations around \(u\). This information must be determined some other way. In the applets above, the choice made was to eliminate this rotation by requiring that the projection of the point \((0,0,1)\) in space lie on the vertical axis in the plane -- i.e. \((0,0,1)\) projects to a point of the form \((0,k)\) in the plane.

This choice is admittedly a compromise, but it does simplify the computations tremendously. The formulas for projecting a point \((x_3,y_3,z_3)\) in space to a point \((x_2,y_2)\) in the plane, using the view angles \(a\) and \(b\), are

In more advanced form, the problem can be stated by first noting that three real parameters are needed to describe all 3-by-3 orthogonal matrices with determinant +1, corresponding to transformations between orthonormal right-handed coordinate systems in space (graph rotations), but mouse motions in the applet can only supply horizontal and vertical data, filling in just two of these parameters.

The next article in this series will address some more advanced features of three-dimensional graphics, in particular how surfaces in space are presented in a graph. Our first applet shows the surface given by \(z = (x^2 - y^2)/8\), a hyperbolic paraboloid, using a wireframe presentation in which the surface appears to be transparent. Parts of the surface that are farther away from the viewer appear faded to a lighter color -- this is based on a common artistic trick, of fading or blurring objects in the background while keeping foreground objects sharp and high-contrast.

In the applet shown here, the same surface is presented along with the surface \(z = (x^2 + y^2)/4 - 5\), a circular paraboloid, but now in a faceted presentation in which the surfaces appear to be opaque, so that foreground parts of the surfaces actually conceal background parts. As shown, the facets are triangular and are large enough that the intersection between the surfaces is imprecise. Again, background parts are faded, but now only to be sure that foreground and background parts are not exactly the same color. The problem is how to determine when one facet is in front of another. The general technique is to sort the facets from back to front and draw them in that order, opaquely, so that facets in front overdraw facets in back. But the sorting may not work out well if the facets are irregularly shaped or if they intersect in some way -- in the applet, facets in one surface intersect facets in the other surface in ways that present such problems.

More precise graphs showing intersections of surfaces can be drawn by subdividing the facets when they intersect, but computing such subdivisions may be too complex to be handled feasibly in an environment such as the Java runtime bytecode interpreter. More powerful three-dimensional graphing packages, such as the Java3d extensions, implement these routines using fast native binary code. The applets here do not use native binary code, so certain compromises must be made. The next article will consider the motivations and consequences of those compromises, including some interesting three-dimensional polygon geometry and a taste of computational complexity.