Performance

Because of the requirement that these features be usable on mid-range workstations, a number of optimization techniques have to be considered. Some of these techniques are discussed below.

Damage Repair

The time taken to refresh the display for the two-dimensional overlay and shader cursors is dominated by the time taken to redraw the image buffer containing the rendered volume. However, since the geometric primitives that have to be moved (namely, two short lines) occupy only a tiny fraction of the image area, huge gains may be made by redrawing only the sub-image over which the cursor was drawn, effectively reparing the damage caused by drawing the cursor.

This technique of damage repair becomes more complicated when the cursor to be ``undrawn'' is composed of three, possibly large, diagonal lines. The direct approach would be to define a rectangle which encloses all three lines, or to define three rectangles each enclosing a line. Unfortunately, because these lines are large, the result is that most of the image will be redrawn anyway (and possibly redrawn three times in the latter case). The other extreme would be to rasterise the lines into their component points and redraw sub-images containing each point. This technique requires a large number of small images to be drawn, perhaps several thousand. If the overhead of drawing an image is significant, this technique can take longer than simply drawing the entire image.

A compromise is to draw a smaller number (perhaps fewer than one hundred) of larger images. Unfortunately, this compromise is determined by the overheads in the graphics library/window system that is used, and in the performance of the display and host computer, and will probably vary between combinations thereof. Work is being done to determine optimum compromises for some combinations.

Depth Planes

To draw a plane that slices through a rendered volume requires not only the entire image to be redrawn, but also, the entire volume to be re-rendered, at far greater computational cost. If the position of this plane is to be moved interactively by the user, rendering times must be brought down to a small fraction of a second.

Instead of doing a complete render of the volume, a few shortcuts may be taken. First we assume that as the user moves the position of the slice plane. The view position relative to the volume does not change. In the case of a volume rendered with the maximum voxel algorithm, the volume may be rendered to produce not only an image plane (that which the user sees), but also a ``depth plane'' which contains an estimate of the depth of the feature the user sees down each ray (corresponding to each of the image pixels).

This depth plane may then be used to merge the slice plane into the volume in a similar way that the three-dimensional shaded cursor is drawn into the volume. The merging process is done on a pixel-by-pixel basis, hence only requires about operations, whereas rendering the volume requires about operations. This is an enormous saving.

The depth-plane technique may be extended to more complex shading algorithms, such as the ``hot gas'' shader. Here we compute not only the estimated depth, but also the cumulative opacity to that depth and a measure of opacity rolloff beyond that depth. This algorithm assumes that the volume is transparent until the estimated depth is reached, then there is a rapid rise in opacity followed by a gradual decrease. This performs reasonably well for compact, nearly opaque features or extended features. It does not perform well in such cases where there is a compact, translucent feature. By adding another estimate of the depth where the opacity suddenly drops, this case is also covered. There are still other cases where this would prove inadequate. However, in the context of astronomical data these are considered to be of secondary importance. The purpose is to obtain a reasonable first approximation with minimum effort.

The techniques described above deal with avoiding costly rendering operations. When merging a slice plane into a volume, each point on the image plane has to be projected into the volume. The intersection of each projected ray and the slice plane has to be computed and this has to be converted into a depth down the ray. Only then can this depth value be compared with the estimate of the feature depth and a new image pixel computed. The computations involved in finding the depth of the slice plane down a ray tend to dominate the process. It is desirable to have a simple relationship between the position of a slice plane and the depth down a ray of its intersection point with the ray. This relationship exists and is:
 
where t is the distance down the ray of the intersection point in units of , is a unit normal vector to the slice plane, is the ray direction vector, d is the distance from a reference plane parallel to the slice plane (in units of ), and is the vector from the starting position of the ray () to a point on the reference plane (). This is of the form:
 

Once and have been computed for each image pixel, the distance of the slice plane from the reference plane may be altered (by changing d) and a new image can be computed very quickly. It is possible to get update rates of several frames a second on a mid-range workstation.

© Copyright Astronomical Society of Australia 1997