GENERAL INFORMATION:
This code renders a three-dimensional volume onto a two-dimensional
image plane using an optimized ray casting technique developed by
Marc Levoy. A hierarchical octree data structure is used to represent
the scene for efficient access, and early ray termination and antialiasing
are implemented. The best description of the algorithm can be found in:
Jason Nieh and Marc Levoy, "Volume Rendering on Scalable Shared-Memory
MIMD Architectures", Proc. Boston Workshop on Volume Visualization",
October 1992.
A briefer description can also be found in
Jaswinder Pal Singh, Anoop Gupta and Marc Levoy, "Parallel
Visualization Algorithms: Performance and Architectural Implications",
IEEE Computer, July 1994.
Further references to the sequential algorithm are contained in those
papers, and a detailed description will be in the SPLASH-2 report.
RUNNING THE PROGRAM:
To see how to run the program, please see the comment at the top
of the main.C file or run it as "VOLREND -h". The base problem we
recommend does not use adaptive pixel sampling, so it would not use
the -a flag.
One compile-time parameter that can be specified in the makefile
is FLIP. This is used only in the I/O routines in file.H, and
specifies whether to reverse byte ordering when reading or writing
files. Thus, if input files were written previously with one
byte ordering and are read using another byte ordering, the program
will crash with an error message ("Can't load version ... file").
If this happens, you need to define/undefine FLIP to make sure the byte
ordering that is in the input file and what the program is expecting
are the same.
The file user_options.H contains a number of compile-time options that
dictate what the program does. That file describes how to use them.
Basically, there are two steps in the application: the first preprocesses
the input .den file and generates the octree, the normal table, and the
opacity table; the next phase takes these structures as inputs and
does the parallel rendering. One mode of the program is to only render,
reading in the octree, opacity table and normal table from precomputed
input files (.pyr, .opc and .norm, respectively). This is the default
mode of the program, and is obtained by setting the RENDER_ONLY compile
time flag. If RENDER_ONLY is not defined, then the program will
not use these files but start from the .den file itself. In this case,
there are two options: if PREPROCESS is defined, then the program will
not render, but will create the .norm, .opc and .pyr files from the .den
file for a future run of the program to render. If PREPROCESS is not
defined either, then the program will not produce these intermediate
files: It will start from the .den file, create the normal and opacity
tables etc as internal data structures, and render from them directly.
The SERIAL_PREPROC option tells whether the preprocessing phases (computing
the normal table or .norm file, etc.), should be done serially or in
parallel, when they are done.
If none of the three options are defined (RENDER_ONLY, PREPROCESS and
SERIAL_PREPROC), the default is to do parallel preprocessing and
rendering without storing intermediate array values.
In the base problem we recommend, we suggest doing the preprocessing first
off-line (perhaps serially), and then timing the parallel rendering part
only.
We provide three input .den files. head.den is a file containing a
256-by-256-by-126 voxel head. head-scaleddown2.den scales this down
by a factor of two in each dimension, and head-scaleddown4.den by
a factor of 4 in each dimension (head-scaleddown4 is thus clearly
only for testing).
There is a run-time command-line flag (-a) that controls whether
adaptive pixel sampling is done. We do not do it in our base problem.
If you use it, please say so explicitly in any results you present.
Please also report the block size used for adaptive sampling (see code,
HBOXLEN parameter in user_options.H) in this case.
There are several other compile-time parameters in the code, mainly in
user_options.H and const.H. They have default values which we describe
below. These are the values that we recommend for the base problem. If
you change them, please say so explicitly in any results you present.
The main parameters of interest are:
user_options.H:
BLOCK_LEN is the size of an image tile (in pixels: BLOCK_LEN by
BLOCK_LEN) which is the unit of task stealing (see papers
cited above). We recommend leaving this at 4.
DIM: if set, DIM says to perform rotations of the volume (from
one frame to the next) in each of the three spatial dimensions.
Default is to do it only in one preset (the Y) dimension.
We recommend not setting DIM in the base problem.
const.H:
ROTATE_STEPS: The number of frames to be rendered (if DIM is set,
then 3*ROTATE_STEPS frames are rendered).
STEP_SIZE: the degree of rotation between frames.
Other parameters should be left as they are.
The volrend program generates a number of tiff files, one per frame,
that can then be viewed on a workstation. Thus, the program
needs a tiff library to run (see Makefile). The PBMPLUS tiff library
works with this application.
BASE PROBLEM SIZE:
As stated above, we provide a 256-by-256-by-126 voxel human head data set,
and two scaled down versions of the same data set. The base problem
we recommend is the 256-by-256-by-126 data set. We shall soon provide
a way to generate larger data sets. Our base problem renders 4 frames,
with DIM turned off (i.e. rotating in only one --- the Y --- dimension).
The STEP_SIZE is 3 degrees. And the BLOCK_LEN (the length of the square
tile of pixels that is the unit of task stealing) is 4.
DATA DISTRIBUTION:
Data distribution is difficult in a shared address space version
of volume rendering (and, if it is required as in a message-passing
abstraction, requires a different algorithm: see the paper
cited above). One could place a processor's portion of the image
plane in its local memory. For the volume, however, particularly given
changing viewpoints from which the scene might be rendered,
it is very difficult to place scene data appropriately in physically
distributed main memory. Data distribution, however, does not make
much difference to performance on the Stanford DASH multiprocessor.
Sanchayan Maity
0f4b39775c