Running CAVE Apps on a Curved Screen Display

These notes are based on our experiences using a Panoram GVR-120 system in the Electronic Schoolhouse at Siggraph '99. The information should be applicable to other large curved displays, such as those from Trimension.

The GVR-120 itself is a curved screen 5'8" tall (set about 40" off the floor in our case), and 18'11" long. It covers roughly 110 degrees of arc (i.e. nearly one third of a complete circle). It uses 3 Electrohome Marquee projectors. The images from the projectors overlap by 25%; special edge-blending hardware is used to produce a seamless image. A number of different computers and video sources may be connected to the system; the CAVE applications ran on a deskside Onyx2/IR, using 3 video channels from 1 pipe (it would also be possible to use a 3 pipe IR).

Normally a Panoram is run monoscopically, with no tracking - users are seated, and interact using a mouse and keyboard or other typical desktop interfaces. For the Siggraph demo, we added a Flock of Birds tracking system, EVL wand, and NuVision stereo glasses.

The Display

In the case of a 3 channel, 1 pipe system, the IR is configured with a 3200x1024 managed area; each channel is 1280x1024, and the overlap regions are 320 pixels wide. Like this, roughly:

For stereo, the IR theoretically has just enough bandwidth for 3 1024x768 96Hz channels, but this only works if they're stacked vertically. When the channels are arranged horizontally, they require about 101% of the IR's maximum bandwidth. So, we had to reduce the size of the channels to 1024x764 in ircombine. They were laid out in the same way as above, but covering a 2560x764 area, with 256 pixel wide overlaps.

When setting up a CAVE configuration for this sort of display, however, all this business of multiple channels and overlapping regions is unimportant and should be ignored (this is not the case in a 3 pipe setup, which will be covered later). The Panoram system is designed to make all this transparent. The effective result is that you have a single 3200x1024 or 2560x764 display covering the entire screen. The CAVE config should just be created with this in mind.

The CAVE Config

The configuration elements that must be worked out now are those for the display - Walls, WallDisplay, and ProjectionData. The number of walls and their projection data will be chosen to approximate the shape of the curved screen to whatever degree is considered good enough. Any number of virtual walls may be used, from 1 to 8 (more will be possible in future CAVElib versions). In many cases, a single flat wall is sufficient; most non-CAVE applications that are run on these systems just open a single window covering the entire screen area and use a single perspective projection. Using more projection planes will produce a more accurate rendering, but (as always) only for a single viewpoint. If you have a tracked user interacting with the virtual world, this may be important. If you have a large non-tracked audience, it may be unimportant; in fact, the incorrect perspective of a single projection plane may be preferrable to the "bent lines" that occur when using multiple planes. As an additional consideration, configuring more walls will increase your graphics load, as each wall requires a separate rendering pass; the increased cost will be primarily in transformations - the fill load should be about the same, and so the net result depends on the application.

For a single projection plane, the configuration file will be something like this:

  Walls screen0
  WallDisplay screen0 :0.0 2560x764+0+0
  ProjectionData screen0 * wall -93 40 -49  -93 105 -49  93 40 -49 inches

This is for a screen set 40" off the ground, 65" tall and 186" wide. Note that the width here refers to the straight line distance from one edge to the other, not the length of the entire curved screen itself. If you have a head-tracked user, it is probably best in this case to put the virtual screen at or close to the back of the physical screen; that is, set the Z component of the projection data equal to the Z of the middle of the screen (relative to your CAVE origin). This will cause the perspective inaccuracies to be greatest at the edges of the display, rather than at the center. Alternatively, putting it a few inches in front of the middle of the screen should reduce the error at the edges a bit, without increasing it too much at the center.

To get a more accurate projection, for a tracked user or a user at a fixed, known location, either 3 or 5 CAVE walls are good choices. They will be laid out roughly like this:

To calculate screen corners for these projection planes, it is best to know radius of the cylinder that the screen forms a part of, and the angle of arc that the screen covers (this all assumes the screen's curve is in fact a fraction of a cylinder). Note that people using these systems sometimes claim a certain "field of view" angle for the displays - do not assume that this is the angle you need; a FOV number is not really meaningful for a projection screen, since the actual FOV depends on how far the user stands from the screen. The number that's really needed is the number of degrees of arc. This can be calculated with a little trigonometry and a tape measure if it's not known (see the very end of this document).

The CAVE screens can be laid out in any shape to approximate the physical curved screen, but it's probably simplest to place the corners of the screens coincident with the physical screen, and to divide up the arc evenly among them. i.e., for 3 screens:

In this configuration, r is the radius and A is the arc of the screen. The corners of the screen are:

   X0 = -R * sin(A/2)
   Z0 = -R * cos(A/2)

   X1 = -R * sin(A/6)
   Z1 = -R * cos(A/6)

   X2 = R * sin(A/6)
   Z2 = -R * cos(A/6)

   X3 = R * sin(A/2)
   Z3 = -R * cos(A/2)

The Y values are just the height of the top and bottom edges of the physical screen. Note that you will have to add some fixed offset to these values if you want your CAVE origin to be at a different point than the center of the screen's circle. Typically, you would just offset the Z values, leaving X=0 at the center of the screen.

In the display we used at Siggraph, the radius turned out to be about 114 inches, and the arc about 110 degrees. The CAVE config for a 3 screen layout in this case would be:

 Walls screen0 screen1 screen2
 WallDisplay screen0 :0.0 854x764+0+0
 WallDisplay screen1 :0.0 852x764+852+0
 WallDisplay screen2 :0.0 854x764+1706+0
 ProjectionData screen0 * wall -93.4 40 -65.4  -93.4 105 -65.4  -35.9 40 -108.2  inches
 ProjectionData screen1 * wall -35.9 40 -108.2  -35.9 105 -108.2  35.9 40 -108.2  inches
 ProjectionData screen2 * wall 35.9 40 -108.2  35.9 105 -108.2  93.4 40 -65.4  inches

A 5 screen configuration can be done similarly. Simply divide up the arc and the framebuffer into 5 equal segments.

Three Pipe Mode

This part is purely speculative, as I have no direct experience with a Panoram or similar system running off of a 3 pipe Onyx. Feedback or corrections from anyone who has in fact used such a system will be welcome. In contrast to what was said above, in a 3 pipe system the amount of overlap between the different video channels will make a difference, so the calculations done here should be adjusted if your system has a different amount of overlap.

In a 3 pipe setup, each pipe will output a single video channel, which will take the place of one of the video channels in the single-pipe setup. That is, each pipe will output a single 1280x1024 or 1024x768 image, and these images must match in the overlap regions which are blended on the screen. It's not possible to open a single window which spans multiple pipes, so you will have to configure multiple CAVE walls. Because the images should match exactly where they overlap, the geometry of the CAVE walls that cover corresponding regions must be exactly the same.

The easiest way to do this is to do the equivalent of the single projection plane configuration described earlier. We will then have three co-planar projection planes, like so:

Because the Panoram system overlaps the images by 25%, the overall display is 2.5 screens wide; so each projection plane should cover 1/2.5 of the larger, single plane. Thus, the configuration, using the geometry from the first example, would be:

  Walls screen0 screen1 screen2
  WallDisplay screen0 :0.0 1024x768+0+0
  WallDisplay screen1 :0.1 1024x768+0+0
  WallDisplay screen2 :0.2 1024x768+0+0
  ProjectionData screen0 * wall -93 40 -49  -93 105 -49  -18.6 40 -49 inches
  ProjectionData screen1 * wall -37.2 40 -49  -37.2 105 -49  37.2 40 -49 inches
  ProjectionData screen2 * wall 18.6 40 -49  18.6 105 -49  93 40 -49 inches

Other notes

Some miscellaneous notes on our experiences:

The projectors did not have P43 (fast-decaying phosphor) green tubes. The Panoram engineers indicated that these tubes would be much more difficult to color balance to provide a seamless display. They also claimed that they have run stereo in the past using non-P43 projectors, without having the ghosting problems that originally led to the need for P43 tubes in the CAVE. However, at Siggraph we clearly saw green ghosting in the bottom third of the display, especially in applications with high-contrast imagery; when there was less sharp contrast in the images, the ghosting was not so noticeable.

The loaner Onyx2 had 2 RM boards. When configured with the very large managed area required by the Panoram (3200x1024), the IR could only use small pixels. This means that no multisampling is available. This in turn affected the transparency in some of our applications - in a typical CAVE or IDesk system, with enough resources for medium or large pixels, Performer uses MSALPHA transparency by default, which reduces the need for back-to-front sorting of transparent objects; with small pixels, it used alpha-blending transparency instead. Some of our applications used transparent models which intersected each other, or had one inside the other; this made it impossible for Performer to always do correct back-to-front sorting, and thus produced errors (objects appearing & disappearing) which we do not normally see in a CAVE or IDesk. With 4 RM boards this problem would presumably go away; using 3 separate pipes would of course also fix it. One other thing to note - ircombine has an option that can force an IR to use small pixels even when it could do better; this could be used when testing applications which will later be run on a system such as the one we used at Siggraph.

This is the method that I worked out for computing the radius and arc of the screen, when making a multi-wall configuration. Measure the straight line distance between the left and right edges of the screen; call this X. Then measure the "depth" of the screen; that is, the distance from the middle of the screen to the middle of the chord you just measured between the two edges; call this Z. Then d, the distance from the center of the screen's circle to the chord, is:

    d = ( X*X/4 - Z*Z ) / (2*Z)

The arc of the screen A is:

    A = 2 * arctan((X/2)/d)

And the radius r is:

    r = d + Z

The derivation of these formulae is left as an exercise for the reader.

Last modified 24 August 1999.

Dave Pape, pape@evl.uic.edu