These opinions may be rooted more in the history of these two fonts than in their design. The scorn may be more toward Microsoft than toward the angled terminals. Personally, I’ve got no opinion. Objectively, the differences are slim.

To make these differences clear, I’ve overlaid Helvetica in magenta with Arial in cyan, and shown their intersection in black. Here is a 75K PNG. If you want to look closely, here is a 152K PDF.

This image was algorithmically generated by a Haskell program which output SVG to be loaded into Adobe Illustrator for titling. Here’s a PDF.

With that in mind, we turn to the problem of list shuffling. Given a list, return a copy of the list with the elements randomly reordered. The great Oleg Kiselyov discusses the problem here. Oleg provides two solutions: a straightforward O(n²) solution, and a more sophisticated O(n log n) approach using binary trees.

The sophisticated approach is a little verbose IMO, and it seemed that an equally efficient yet more terse example could result from the realization that list shuffling resembles the Quicksort algorithm. If you replace the value test with a random outcome, the result should be a random ordering of the list in O(n log n) time. Here’s an implementation:

import Random

shuffle xs g = fst (mix xs (randomRs (True, False) g))

    where mix [ ] r0 = ([ ], r0)
          mix [x] r0 = ([x], r0)
          mix  xs r0 = let (ys, zs, r1) = cut xs r0 [] []
                           (cs,     r2) = mix ys r1
                           (ds,     r3) = mix zs r2
                       in  (cs++ds, r3)

          cut    []     rs  ys zs = (ys, zs, rs)
          cut (x:xs) (r:rs) ys zs = if r then cut xs rs (x:ys) zs
                                         else cut xs rs ys (x:zs)

The cut function randomly distributes the elements of a list between two new lists. The mix function recursively shuffles these two new lists and concatenates the results. The shuffle function takes a Haskell StdGen which it uses to produce an infinite list of pseudo-random booleans. Note that this list of booleans must be passed to and returned from every function internally. Such is the cost of pure functional code. Use it like this:

*Main Random> shuffle [1..10] (mkStdGen 3)
[1,6,2,5,4,10,3,8,7,9]
*Main Random> shuffle [1..10] (mkStdGen 10)
[2,1,5,3,6,7,10,8,4,9]

I had prior experience with real-time dome rendering, having done early work with programmable GPUs in a 4-meter dome at NASA Langley Research Center in 2002. I had spent my years in Chicago adapting real-time visualization code to a wide array of display technologies, and the digital full-dome was another challenge in that vein. It was my further intention to adapt my doctoral work to the full-dome display and defend my dissertation interactively in the Adler dome. The convergence of these influences coincided with IPS 2008, and I was invited to present an overview of real-time dome rendering techniques at the conference.

The resulting paper gave broad coverage of real-time display and spherical correction techniques, targeted toward the non-technical planetarium crowd, and intended to teach them a bit about the nature of 3D graphics hardware and its incompatibility with domes. I recently decided to revisit and revise this paper. Here’s the PDF.

It was a great experience. The Atlas V launched on June 18th, the first available launch day. A bank of low clouds had rolled in just prior to the launch, so the rocket itself was only visible for about a minute before lighting up the overcast and disappearing from view. It was an impressive spectacle for that minute, burning with an intense orange light. The sound was a massive rumble with a sharp crackle, continuing well after the rocket had gone out of sight.

Shuttle Endeavour had been having trouble on the pad due to a hydrogen leak. They made one last attempt to fuel late in the evening of the 16th. Had they succeeded, we could have watched an early morning launch from our hotel balcony along the beach to the south. However, the leak persisted and the launch of Endeavour was scrubbed. Our bonus rocket launch was not to be.

While waiting for the launch of the Atlas V carrying LRO/LCROSS, I took the opportunity to snap a few photos in and around the Saturn V Facility near the launch viewing stands. It’s all huge, so I decided to stitch some panoramas. These were created using Autopano Pro and touched up using Photoshop.

KSC as seen from the launch viewing stand [9969x719, 1.0MB]

The Saturn V [5290x1272, 1.3MB]

Another view of the Saturn V [4961x950, 1.0MB]

The business end of the Saturn V [2442x2273, 1.2MB]

In my case, I needed to run a computation involving numerical integration using IEEE double precision floating point values, and output the resulting table of values to a file for visualization. Implementing this computation in Haskell was great fun. However, when it came time to store the output I discovered that Haskell’s IO libraries are very text-oriented. Binary IO functionality was not to be found.

I googled around, as one does, and came up empty-handed. There is a module called Data.Binary, but its purpose is serialization rather than raw IO, so the binary files it produces include header data. The Data.Array.IO module supports doubles, but only supports IO on bytes, and does not properly maintain the array length when casting from double. Finally, there’s this ridiculous mailing list thread that actually presents code to pack and unpack IEEE values from raw bytes. I boggled at the notion of a language that forces the programmer to implement their own IEEE 754 packer.

Fortunately, I was looking in the wrong place. It turns out that Haskell categorizes double IO functionality as “foreign”. The Haskell Foreign Function Interface defines sufficient functionality to pack doubles into a buffer and output them to a file. I guess that makes sense if you consider the operating system (or the floating point processor itself) to be something apart from the Haskell system.

So here’s some code. It writes the numbers 1 through 8 to a file named foo.dat. The System.IO import provides the file handle and the withBinaryFile function to open and close it. Foreign.Ptr defines the concept of a pointer to an array of doubles. Foreign.Storable provides peek and poke functions to manipulate that array. Foreign.Marshal.Array brings malloc to the party.

import System.IO
import Foreign.Ptr
import Foreign.Storable
import Foreign.Marshal.Array

writebin h = do a <- mallocArray 8 :: IO (Ptr Double)
                pokeElemOff a 0 1.0
                pokeElemOff a 1 2.0
                pokeElemOff a 2 3.0
                pokeElemOff a 3 4.0
                pokeElemOff a 4 5.0
                pokeElemOff a 5 6.0
                pokeElemOff a 6 7.0
                pokeElemOff a 7 8.0
                hPutBuf h a 64

main = withBinaryFile "foo.dat" WriteMode writebin

And that's all I need. I hope you can stop googling now and get something done.

I don’t claim to know what good code is shaped like, and I don’t know what impact an awareness of your code’s shape might make on its design, but I think the images are neato and I wanted to see the contour of my current project, which consists of around 34K lines of C++ code spread across 156 source and header files. The means of generating such images was not immediately obvious to me, so I developed the following technique using utilities commonly found on any Unix-like system.

As an overview: we convert text to image by way of Postscript. Enscript generates color syntax-highlighted vector output which is converted to a raster image by Imagemagick.

The primary difficulty lies in eliminating page breaks and generating a continuous scroll. To accomplish this, define a new Enscript media type called “Scroll,” representing a very long narrow page. To use it, place the following text in the Enscript configuration file, ~/.enscriptrc:

Media: Scroll 512 32768 0 0 512 32768

Given this, here is a command line to generate hello.cpp.png from the text of hello.cpp. Enscript writes its output to stdout, which is piped into the stdin of convert.

enscript --no-header -Ecpp --color -MScroll -p - hello.cpp | convert ps:- -flatten -resize 25% -trim -normalize -quality 100 -colors 16 hello.cpp.png

This code…

#include <iostream>

int main()
{
    std::cout << "Hello, World." << std::endl;
}

… produces this image.

Here’s a larger example (122×2510)

There are many opportunities for customization. Lets begin with the Enscript options. The --no-header option tells Enscript to print nothing but the file’s contents, omitting the header line it would normally include. The -Ecpp option tells Enscript to highlight the syntax of C++ code. Run enscript --help-pretty-print to see a list of all supported languages. The --color option requests colored syntax, which defaults to an Emacs style. -MScroll selects the long page media type we’ve just defined. Finally, -p - tells Enscript to write the generated Postscript to stdout.

Now take a look at the Imagemagick options. Postscript is assumed to be transparent, and I want an opaque image, so the first step is to -flatten the input. Then, we do the work we set out to do in the first place, -resize 25% to scale the image down. A value of 10% is probably more appropriate if you want something resembling one pixel per character, as Enscript renders the text using 10-point Courier. The -trim option eliminates blank space at the end of a page (more on that issue below). -normalize enhances the contrast. This is necessary because text tends to have more background than foreground. The default down-sampling filter averages these, resulting in colors near white. Finally the -quality 100 and -colors 16 options configure the PNG compression. Sixteen colors are probably enough, as highlighted syntax usually has only a few colors, but we’d like a few extras for antialiasing.

Now, for this to be really useful we’ll want to automate it. We want to generate a complete set of images including every source file in a project. This can be easily done with GNU make. Here’s a Makefile:

SRCS= $(shell find . -name "*.cpp" -or -name "*.hpp")
IMGS= $(SRCS:%=%.png)

ESFLAGS= -Ecpp --no-header --color -MScroll
CVFLAGS= -flatten -resize 25% -trim -normalize -quality 100 -colors 16

%.png : %
	enscript $(ESFLAGS) -p - $< | convert ps:- $(CVFLAGS) $@

images : $(IMGS)

Given this, all we need to do is type make images and make will seek out all C++ source and header files (that's the find operation in the definition of SRCS), determine an appropriate PNG image name for each (the definition of IMGS) and generate PNGs as above. As with most make-based processes, the next time we make images, make will generate PNGs only for those source files that changed since the last run.

Lastly, a note on source length: Notice that the Postscript Scroll media type defined above is only 32768 points long. That's about 5000 lines of program text. If your source file is longer than that, then it will be paginated on the pipe, and convert will generate only one image. Yet, we can't freely set that value larger because the generated Postscript will, in fact, always be exactly 32768 points long. Thus when Imagemagick begins processing there is briefly a raster buffer large enough to accept it. The -trim optimizes this by slicing away any blank space. This is the ugly side of this technique. If you know of a way to get Enscript to automatically adapt its media size to the output, let me know. If you know of a completely different and vastly superior means of program contour image generation, let me know that too.

Perspective projection is a well-understood aspect of 3D graphics. It is not something that 3D programmers spend much time thinking about. Most OpenGL applications simply select a field of view, specify near and far clipping plane distances, and call gluPerspective or glFrustum. These functions suffice in the vast majority of cases.

But there are a few assumptions implicit in these. gluPerspective assumes that the user is positioned directly in front of the screen, facing perpendicular to it, and looking at the center of it. glFrustum generalizes the position of the view point, but still assumes a perspective rooted at the origin and a screen lying in the XY plane.

The configuration of the user and his screen seldom satisfy these criteria, but perspective projection remains believable in spite of this. Leonardo’s The Last Supper appears to be a painting of a room full of people regardless from the position from which you view it, and we still enjoy a movie even when we’re sitting off to the side of the theater.

Motivation

The field of Virtual Reality introduces circumstances under which these assumptions fail and the resulting incorrectness is not tolerable. VR involves a number complicating aspects: first-person motion-tracked perspective, stereoscopic viewing, and multi-screen, non-planar display surfaces. For example, this is the Varrier^TM.

This technology was invented at the Electronic Visualization Laboratory at the University of Illinois at Chicago. The Varrier installation pictured here can be found at Calit2 on the campus of the University of California at San Diego. It is a 12×5 array of LCD screens arranged in a 180 degree arc, 10 feet in diameter. Each LCD displays 1600×1200 pixels, with a parallax barrier affixed to the front, giving autostereoscopic viewing. (That’s 3D without glasses. See this SIGGRAPH 2005 paper for background.) The display as a whole is driven by a cluster of 16 Linux PCs, each with two NVIDIA GeForce 7900 GTXs, with 4 displays connected to each cluster node.

As is common in VR systems, a motion tracking system senses the position and orientation of the user’s head. This allows the 3D spatial positions of each of his eyes to be computed relative to the position of the display, which leads to the first-person tracked perspective aspect of VR. Here is a top-down view of the 60-panel Varrier showing the coordinate system of the motion tracker.

The origin of the tracker coordinate system is on the floor at the center of the arc, the X axis points to the right, Y points up (out of the image), and Z points back. In the photograph above, I’m standing a bit right of center, and I’m 5′10″, so my tracked head position is around (2.0, 5.8, 0.0).

To display a single coherent virtual environment, all 60 screens must define their projections in a common coordinate system. For convenience, we simply reuse this tracker coordinate system for this purpose. The positions of the corners of all 60 screens have been measured very precisely in this coordinate system using a digital theodolite. Given these positions, plus the tracked position of the user’s head, we can compute the positions of the users eyes, and thus the 120 distinct perspective projections necessary to render one scene consistently across the entire cluster.

Now, because the user is free to move about the space, the view position does not remain centered upon any of the screens and the gluPerspective function fails. Because the display wraps around the user, most screens do not lie in the XY plane and the glFrustum function fails. We must therefore formulate a more generalized perspective projection.

In the coming sections we will build up such a formulation from basic principles, mathematically, in stages. Our ultimate degree of generality will surpass even the needs of the Varrier. Following that, we will see the implementation of this more general approach to perspective projection in C using OpenGL. Finally, we will play with a very simple example which uses the generalized projection to render crossed-eye stereo pairs suitable for viewing on a normal 2D display.

Formulation

The perspective projection is determined separately for each screen-eye pair, so we need only consider a single screen being viewed by a single eye. Here is a screen:

The important characteristics are the screen corners p_a at the lower left, p_b at the lower right, and p_c at the upper left. These values encode the size of the screen, its aspect ratio, and its position and orientation in space.

We can use these three points to compute an orthornormal basis for the screen space. Recall from linear algebra class that an orthonormal basis for a 3D space is a set of three vectors, each of which is perpendicular to the others, and all of which have length one. In screen space, we refer to these vectors as v_r, the vector toward the right, v_u, the vector pointing up, and v_n, the vector normal to the screen (pointing directly out of it.)

Just as the standard axes x, y, and z give us an orthonormal basis for describing points relative to the origin of 3D Cartesian space, the screen-local axes v_r, v_u, and v_n give us a basis for describing points relative to the screen. We compute these from the screen corners as follows:

On-axis projection

Now, here is an eye position p_e.

Notice that in this specific example, the eye is centered on the screen. The line drawn perpendicular to the screen along v_n strikes it directly in the middle. We refer that point of intersection as the screen-space origin. This coincides with the origin of the screen-space vector basis depicted above.

Also in this example, the pyramid-shaped volume, or “frustum,” having the screen as its base and the eye as its apex is perfectly symmetric. This is exactly the type of perspective projection producted by gluPerspective.

Off-axis projection

If we move the eye position away from the center of the screen, we get a situation like this:

The frustum is no longer symmetric, and the line from the eye drawn along v_n no longer strikes the screen in the middle. We defined the screen-space origin to be this point of intersection, and we continue to do so, thus we see that when the user moves then the screen-space origin moves with him.

This is where glFrustum comes in. As documented, this function takes parameters giving the left, right, bottom, and top frustum extents, plus distances to the near and far clipping planes. We will refer to these as variables l, r, b, t, n, and f respectively. The first four frustum extent variables may be understood as tracker-space distances from the screen-space origin to the respective edges of the screen, as shown here:

In this example, l and b are negative numbers, while r and t are positive numbers, but this need not be the case. If the user moves far to the side of the screen, then the screen space origin may not fall within the screen at all, and any of these parameters may be positive or negative.

Determining frustum extents

Before we may use these values, we must compute them. As an intermediate step, we will need to know the vectors from the eye position p_e to the screen corners.

These vectors are trivially computed as follows:

It is also useful to know a bit more about the screen-space origin. In particular, let d be the distance from the eye position p_e to the screen-space origin. This also happens to be the length of the shortest path from the eye to the plane of the screen. This value may be computed by taking the dot product of the screen normal v_n with any of the screen vectors. Because these vectors point in opposite directions, the value must be negated.

Given this, frustum extents may be computed. Take the frustum right extent r for example. When we take the dot product of the unit vector v_r (which points from the screen origin toward the right) with the non-unit vector v_b (which points from the eye to the right-most point on the screen) the result is a scalar value telling us how far to the right of the screen origin the right-most point on the screen is.

Because frustum extents are specified at the near plane, we use similar triangles to scale this distance back from its value at the screen, d units away, to its value at the near clipping plane, n units away.

The OpenGL function glFrustum inserts these values into the standard 3D perspective projection matrix, which is defined as follows:

This matrix is clever, and it is worth examining in order to form an intuitive understanding of its function. Perspective projection involves foreshortening. The greater the distance to an object, the smaller that object appears. To accomplish this, the x and y components of a vertex are divided by its z component.

This division is implemented using homogeneous coordinates. A homogeneous 3D vector has 4 components, (x, y, z, w), where w defaults to 1. This implicitly defines the 3D vector (x/w, y/w, z/w). Notice the 3rd component of the bottom row of P is -1. When P is multiplied by a homogeneous vector, this -1 has the effect of moving the vector’s (negated) z value into the resulting homogeneous vector’s w component. Later, when this result vector is collapsed down to its equivalent 3D vector, the division by z implicitly occurs.

This implies that the foreshortening effect, and thus perspective projection, only works when the view position is at the origin, looking down the negative Z axis, with the view plane aligned with the XY plane. The foreshortening scaling occurs radially about the Z axis. It is useful to understand these limitations and their source, as we’ll need to work past all three.

Deep breath

Let’s take a step back and see where we are. We’ve started with basic constants defining the position of a screen in space p_a, p_b, and p_c along with the position of an eye in space p_e. We’ve developed formulas allowing us to compute from these the parameters of a standard 3D perspective projection matrix l, r, b, and t.

It’s a good start, but we haven’t fundamentally created anything more powerful than glFrustum yet. While we have the ability to create a frustum for an arbitrary screen viewed by an arbitrary eye, the base of that frustum still lies in the XY plane. If we applied this amount of knowledge to the Varrier, then all 60 screens would display nearly the same limited view of the virtual scene. We need two more capabilities: first we need to rotate the screen out of the XY plane, and second we need to correctly position it relative to the user.

Projection Plane Orientation

We would like to rotate our XY-aligned frustum within the tracker space. We may do this with a simple matrix multiplication. To understand how, it becomes more intuitive if we instead consider rotating the tracker space to be aligned with the XY plane.

Let’s review a bit more linear algebra. Define a 4×4 linear transformation matrix M using the screen space basis vectors v_r, v_u, and v_n as columns, like so.

This is the transformation matrix for screen-local coordinates. It maps the Cartesian coordinate system onto the screen space coordinate system, transforming the standard axes x, y, and z into the basis vectors v_r, v_u, and v_n. If something is lying in the XY plane, then this transformation matrix M will realign it to lie in the plane of the screen.

This is extremely useful in 3D graphics. A 3D model is created by an artist in its own coordinate system, with its own local orientation. To position such an object in a scene, a transformation such as this M is used. The column basis construction allows the programmer to orient the object in terms of the concepts “to the right,” “up,” and “backward” instead of fumbling with Euler angles, pitch, roll, and yaw.

Unfortunately, this is the exact opposite of what we want. We want something lying in the plane of the screen to be realigned to lie in the XY plane, so that we may apply the standard perspective projection to it. We need this mapping:

This mapping is produced by the inverse of M. Fortunately, M is orthogonal, so its inverse is simply its transpose, and we can produce the desired transform simply by loading the screen space basis vectors into M as rows instead of as columns.

We compose the perspective projection matrix P defined above with this matrix M and we finally have something more powerful than glFrustum. We have a perspective projection that relaxes the projection plane alignment requirement. But we’re not quite finished yet.

View point offset

The nature of the camera is one of the fundamentally confusing aspects of 3D computer graphics. Consider camera motion. While we would like to imagine that we are free to move the camera freely about 3D space, the mathematics of perspective projection as defined by matrix P disallow this. (Recall, above, the nature of the foreshortening division by z.)

The camera is forever trapped at the origin. If we wish to move the camera 5 units to the left, we must instead move the entire world 5 units to the right. If we wish to rotate the camera clockwise, we must instead rotate the world counterclockwise.

Above, when we wanted to rotate our frustum to align it within our tracker space, we instead rotated our tracker space to align it with our frustum. Now, we want to move our frustum to position the apex upon the motion-tracked eye position, so we instead must translate our tracked eye position to the apex of of our frustum. The apex of the perspective frustum is necessarily at zero, thus we translate along the vector from the eye.

This can be accomplished using the OpenGL function glTranslatef, which applies the standard 3D transformation matrix:

Composition of everything

That covers everything we need. We can compose these three matrices giving a single projection matrix, sufficiently general to accomplish all of our goals.

Beginning with constant screen corners p_a, p_b, p_c, and varying eye position p_e, we can straightforwardly produce a projection matrix that will work under all circumstances. Most significantly, an arbitrary number of arbitrarily-oriented screens may be defined together in a common coordinate system, and the resulting projection matrices will present these disjointed screen as a single, coherent view into a virtual environment.

Implementation

The following C function computes this perspective matrix and applies it to the OpenGL projection matrix stack. It takes four float vectors, pa, pb, pc, pe, which are the screen corner positions and the eye position as define above, plus n and f which are the near and far plane distances, identical to those passed to gluPerspective or glFrustum.

This function uses 4 vector functions: subtract, dot_product, cross_product, and normalize, which are not listed here, but are included in the example code described below. In all likelyhood, you already have a library containing functions performing the same tasks.

All variables defined in this function have the same names as in the description above. Note that this function is not optimized. The screen space basis vectors, vr, vu, and vn may be precomputed and stored per screen, as may be the screen-space basis matrix M which uses them.

void projection(const float *pa,
                const float *pb,
                const float *pc,
                const float *pe, float n, float f)
{
    float va[3], vb[3], vc[3];
    float vr[3], vu[3], vn[3];

    float l, r, b, t, d, M[16];

    /* Compute an orthonormal basis for the screen. */

    subtract(vr, pb, pa);
    subtract(vu, pc, pa);

    normalize(vr);
    normalize(vu);

    cross_product(vn, vr, vu);

    normalize(vn);

    /* Compute the screen corner vectors. */

    subtract(va, pa, pe);
    subtract(vb, pb, pe);
    subtract(vc, pc, pe);

    /* Compute the shortest distance from the eye to the screen. */

    d = -dot_product(va, vn);

    /* Compute the extents of the perpendicular projection. */

    l = dot_product(vr, va) * n / d;
    r = dot_product(vr, vb) * n / d;
    b = dot_product(vu, va) * n / d;
    t = dot_product(vu, vc) * n / d;

    /* Load the perpendicular projection on the projection matrix stack. */

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glFrustum(l, r, b, t, n, f);

    /* Rotate the projection by applying the screen orientation. */

    M[0] = vr[0]; M[4] = vr[1]; M[ 8] = vr[2]; M[12] = 0.0f;
    M[1] = vu[0]; M[5] = vu[1]; M[ 9] = vu[2]; M[13] = 0.0f;
    M[2] = vn[0]; M[6] = vn[1]; M[10] = vn[2]; M[14] = 0.0f;
    M[3] =  0.0f; M[7] =  0.0f; M[11] =  0.0f; M[15] = 1.0f;

    glMultMatrixf(M);

    /* Move the apex of the frustum to the origin. */

    glTranslatef(-pe[0], -pe[1], -pe[2]);

    glMatrixMode(GL_MODELVIEW);
}

Some may wonder why I’ve chosen to apply the glMultMatrixf and glTranslatef to the OpenGL projection matrix rather than the model-view matrix. It would work either way. I feel the use of the projection matrix lends the implementation better encapsulation. Applications may use it as a drop-in replacement for the standard perspective functions without worrying about smashing a valuable model-view stack with a glLoadIdentity, as is a very common practice.

This distinction is even wider when you consider the OpenGL 3.0 forward compatible and OpenGL ES 2.0 programming models. Both of these APIs do away with the matrix stacks entirely. Applications that use them must construct their projection matrices on the CPU and upload them to vertex shader uniforms on the GPU. By composing the screen-space orientation and eye position translation matrices with the perspective projection on the CPU, the vertex shader need not concern itself with the nature of the projection.

Example

To make this discussion as concrete as possible, there is a complete example application for you to compile and run. It is based upon GLUT, so you should be able to compile and run it under your OS of choice. I have tested it under Linux and OSX. Feel free to copy and paste the source for any purpose you see fit.

A full-fledged multi-screen example would be beyond the scope of this document, given that a great deal of hardware and supporting software is necessary before we can even begin. For this reason, we present a simple, real-time, stereo pair renderer. Here’s a screenshot.

This is a crossed-eye stereo pair. Cross your eyes such that your right eye focuses upon the left image, and your left eye focuses upon the right image. If you have trouble perceiving this image in stereo, see this related post.

Stereo rendering is an excellent application of our projection function, because many stereo application implementors do it wrong. They offset the eyes horizontally but leave the view axes parallel, or they introduce a simple “toe-in” rotation without accounting for the off-axis perspectives. Neither of these approaches cause the left-eye and right-eye projection rectangles to coincide in virtual space, as they should.

The generalized perspective projection formulation allows you to do it correctly and automatically. You need only select one set of screen corners and a pair of eye positions, and the projection function produces a correctly skewed projection. Here is a top-down depiction of the virtual scene depicted by the example code.

This scene is designed to be roughly correct when displayed on a PC or laptop with a display resolution of 100dpi, viewed from a distance of 18″. The 500×250 pixel window should appear approximately 5″×2.5″. The eyes are positioned near the origin, and offset based upon an average interocular distance of 2.5″. The virtual teapot is positioned at z=-16″, and the screen corners have z=-18″. If your display is scaled correctly, then the teapot should appear to hover 2″ in front of your screen.

Extended capabilities

As suggested in the motivation, this perspective function has generality beyond what is commonly needed. In particular, screens may have arbitrary orientation. They may even be rotated, installed upside down, laid flat on the floor, or hung from the ceiling. This makes the approach applicable to CAVE-like projector-based installations. The only requirement is that p_a describe the screen’s structural lower left corner, rather its spatial lower left corner. (And so with p_b and p_c.)

Also note that the ostensibly rectangular screen is configured using only three points. The position of the fourth point is implicit. The formulation discussion refers to the screen-space basis (v_r, v_u, v_n) as “orthonormal”, and the implementation does normalize it, but does not orthonormalize it. Thus, the configuration is free to introduce a skew transform, in addition to the screen-orientating rotation transform. I have never seen a circumstance where this is useful. If you ever find a rhombic display, let me know!

Conclusion

This has been a rather lengthy document describing a fairly brief bit of code. By discussing it in detail, I hope to convey a thorough understanding of its function, correctness, and usefulness. This code has found use in several virtual reality research projects at EVL, and its value to us has been great. I hope you find it useful as well.

Of all of the existing standard-display stereoscopic techniques, wall-eyed and crossed-eye stereo image pairs are the most flexible and reliable. Most people find crossing their eyes to be much easier than wall-eyeing, since we cross our eyes automatically anytime we focus on an object near us. For this reason, I tend to focus upon cross-eyed stereo pairs as a preferred method of presenting stereo imagery on the web.

But despite being the easiest stereo technique to view, many people still have trouble with cross-eye image pairs. It is a skill that gets easier with practice, and some might need a little push to get started. This page exists to offer advice and explanation which will hopefully help some of those who continue to be baffled.

Here is a cross-eye stereo pair of the famous teapot.

When you focus on this image normally, you see a pair of teapots. They are similar, but not identical.

Now, if you cross your eyes you’ll begin to see everything doubled. You’ll see two of each of your hands, two of your computer, and two of the image on your display. You’ll see four teapots.

If you have trouble crossing your eyes intentionally, position your finger half way between your face and your screen. Look at your finger, and in the background you will see the four teapots.

In this image, the pair of teapots that your left eye sees are drawn in red, and the pair of teapots that your right eye sees are drawn in blue.

If the two pairs of teapots are not vertically aligned, then your head is tilted with respect to your screen. This can happen if you’re not sitting directly in front of the screen. Tilt your head until all four teapots are lined up vertically.

Once they’re aligned vertically, adjust the crossing of your eyes until the two teapots in the middle overlap one another.

If you’re using your finger to help you cross your eyes, then move your finger forward and back. While continuing to look at your finger, you will see the pairs of teapots shift horizontally. Adjust the position of your finger until the two middle teapots overlap. Once they are aligned, attempt to shift your focus from your finger to the teapot.

With these two teapots aligned, something in your mind will snap. It will flip on like a switch. What was once a baffling jumble of double vision will suddenly merge into clear 3D image. Once your mind has latched on to this 3D image, you will find it very easy to maintain the illusion.

The solid 3D teapot will be flanked on each side by another teapot afterimage. As you concentrate on the middle teapot, these ghost teapots will become easy to ignore. If they bother you, then you may block these flanking images with your hands, and the 3D illusion will remain.

Here is the stereo pair again. Take a look.

The size and resolution of your display should be such that the distance between the two teapot images is roughly the same as the distance between your eyes. It doesn’t really matter much if this isn’t the case, but it is optimal. It is also more intuitive to understand what’s going on. Here’s a view from above:

Your eyes are crossed. Rather than converging on the screen, as they normally do, they are converging on a point half of the distance to the screen. When you position your finger at that point, you trick your eyes into merging the teapot images on the screen.

The teapot image is an easy one. It displays a single, isolated object against a plain background. This isolated object gives the viewer a well-defined reference to apply the merging described above. Not all stereo pairs have such a useful feature, but most images have some contrast that can be focused upon.

As an example, here is a stereo pair of the constellation Orion and the Hyades cluster. Focus on the large red star Betelgeuse at Orion’s shoulder. Merge that feature, and you will find his club poking out at you. After you’ve settled in to the image, examine the detail in the Hyades cluster at the lower right, and the subtle variation in the carpet of background stars.

Click the image for a larger version. While the larger image will show more detail, it will be more difficult to view, as it will require you to cross your eyes farther.

To find other examples to practice upon, search Google Images for “cross eye stereo pair”.