There are three fundamentally different categories of incremental movement to be considered in this navigation scheme: lateral translation (right, left, up, and down), back-to-front translation (in, out), and rotation (about two different axes). In this section, the computational aspects of these operations are discussed. In the following, the viewing screen is assumed to be perpendicular to the z axis.
3.4.1 Lateral Movement: Due to the geometry of the
viewing pyramid (parallelepiped with front face perpendicular
to a coordinate axis, rays originating from voxel centers,
and movements limited to unit increments),
incremental lateral translations are particularly simple
to compute.
Most of the pixels in the new view are obtained by shifting
the pixels of the previous view left, right, up, or down.
For example,
consider a unit translation to the right, as shown in Figure 8a. A column
of rays are cast at the right end of the screen and a column of
pixels at the left end of the viewing screen are
discarded. Such movements can thus be performed
in 
time.
In addition to translating the view, the data structure
must also be updated. In particular, an additional set of
-voxel segments are rendered and shifted
into the data structure. The time to render these segments
is 
per segment, or 
overall.
3.4.2 Back-to-Front Translation: Forward and backward movements are
more complicated to compute than lateral translations. To update
a volume-rendered view for a one-unit forward translation,
all of the 
pixels in the current view need to be modified.
In particular, an additional voxel must be rendered onto the end
of each ray, and the first sample in each ray should be
`de-rendered' (Figure 8b).
Consider first the simple case of weighted sum projection.
Rendering onto the back of the ray is simply an addition, and
de-rendering is achieved by subtraction. Thus, each ray can be
updated in constant time. The whole view can be updated in 
time, but the data structure requires 
operations to
modify each 
-voxel segment.
Figure 8. Examples of translational movements.
This technique depends upon the ability to specify an easy-to-compute
de-rendering operation corresponding to a given rendering operator.
Other common rendering operations are, unfortunately, more complicated
than weighted sums. Consider, for example, volumetric compositing,
which presents a more complicated form of weighted summation.
Compositing can be done in a back-to-front manner using
the ``merge over'' operator [35]. The color c and opacity
of a voxel are determined
from a look-up table formed from the raw voxel densities. Color can be a
vector of RGB values, or a scalar representing gray scale intensity. The opacity
is a fraction between 0 and 1, where 1 indicates that a voxel is
completely opaque and obscures all samples behind it on the ray, while
0 indicates a completely transparent sample.
The analysis is simplified by using transparencies
rather than opacities.
The transparency of a ray is the product of the transparencies of its sample
points. The color of a ray can be computed as follows. Let A denote the
first p sample points of a ray, and B represent the last n-p
sample points of the ray. Let 
, 
, 
, and 
denote the
colors and transparencies of A and B respectively. The color
c and transparency t of the entire ray can be represented in terms
of 
, 
, 
, and 
as follows:
The colors computed for the entire rays are the values displayed on the viewing screen.
Consider the case of forward movement. A ray is updated by de-compositing the voxel on the front face, and compositing a new voxel onto the back. Let subscript f represent the sample to be decomposited at the front face. Then f can be de-composited by the following equation:
A difficulty with this operation is that the division may cause
numerical instability if opacities are near 
.
The instability becomes more apparent as successive incremental
forward or backward translations are performed. In order to circumvent
the problem, maximum opacities should be limited (e.g., 0.8).
Furthermore, the number of successive forward or backward movements
before refreshing the data structure (phase 1) should be limited.
3.4.3 Rotation: As noted in section 3.3, incremental rotation
of the viewing direction about either the x axis (``tilt'') or
the y axis (``rotation'') can easily be computed if the data structure
contains 
-voxel segments at the correct orientation. In this
case, a new view is computed from the stored intermediate data
in time 
. No updating of the data structure is required.
Up to 
incremental rotated views can generally be computed
in this fashion, until the angle leaves the range of orientations
for which the stored data can be used. Thus, approximately every
-th rotated frame will require an update of the data
structure via phase 1, requiring 
time.
An alternative, in order to try to balance the time taken for each
rotated frame, is to begin computing the next set of 
-voxel
segments immediately, rather than waiting to go out of range.
In this way, the 
update can be amortized over
the set of 
successive rotations, adding 
time to each incremental rotation. This method would be most
valuable if long `sweeps' of the data tend to be performed,
requiring long sequences of rotated frames.