display_volu

Input

a byte per voxel dataset (3D scalar byte field) and a colormap
    which is used to map the data to an ARGB color.
AXIS SCALING:
    All modules supply X, Y, Z scaling functions which can be used to 
    scale independently each major axis of the data to account for
    rectlinear, non-square voxel representations.
AUTO FILL:
    All modules offer a toggle option for the "Auto Fill" function which
    switches on the CUBIC_POLYPOINT auto_fill option.  This flag enables
    a filling algorithm which will render a rectangle for each voxel.
    The rectangle encloses the voxel cube projection and allows the DC
    image to be enlarged without rarifying the appearance of the
    rendered volume.  If this flag is not present, a single pixel is
    modified per data point, regardless of the DC spacing between data
    points.
DOUBLE BUFFERING:
    Many of these modules provide a double buffer toggle.  This switches
    the rendering between single buffering and double buffering.  Note
    that this means that a 12 bit per pixel (4 bits red, 4 bits green,
    and 4 bits blue) effective frame buffer is used for compositing on
    all but the CRX48Z graphics device.  This introduces a major
    quanitization effect to the renderings and may not be very useful
    for many applications.
"display_volume" Module:
    This module takes in a byte/voxel dataset, a colormap, 
    and a transform matrix and renders a volume in a window.
"disp_lit_vol" Module:
    This module also takes in a byte/voxel dataset, a colormap, 
    and a transform matrix and renders a volume in a window.
    The difference with this module is that it implements a form
    of gradient shading.  For coding convenience and speed the light
    source direction has been limited to one of the 26 vectors which
    pass directly through an adjacent voxel.  The gradient magnitude
    is approximated as the magnituded difference of voxel under
    computation and the adjacent voxel along the light source vector.
    This magnitude is store in a second byte (per voxel) along with
    the original voxel scalar magnitude byte.  This 2 byte per voxel
    field is fed to the CUBIC_POLYPOINT gescape along with a table
    which contains a lighting model applied to the original colormap
    supplied to the model.  This lighting model is driven by ambient,
    diffuse, and specular weighting and theta/phi light source angles
    supplied as input parameters.
"display_argb_vol" and "display_argb_vol2" Modules:
    These two modules have identical functionality.
    They both takes in a word/voxel dataset (with packed ARGB) and a
    transform matrix and renders a volume in a window.
    The only difference is that the first module uses the
    PRE_SCALED_ALPHA data form, while the second does not.
    For an explanation of this CUBIC_POLYPOINT option see the
    man page below.
"remote_volume" Module:
    This module prototypes an ability to make use an HP graphics
    devices volume rendering capability remotely.  The idea is 
    to run AVS on the HP with the X display routed to a networked
    server, but make use of the HP workstation and one of the above
    listed display devices to render volume dataset on the HP then
    send the results (as AVS images) to the remote X display.
    To use this module you'll need to setup the environment variable
    COMPUTE_SERVER to point at the X server on the HP server that
    will be performing the rendering. 
    (i.e. "export COMPUTE_SERVER=hp_snake:0.0").
"remote_lit_vol" Module:
    This is another remote rendering prototype, but this time includes
    the same gradient lighting model described for the disp_lit_vol
    module (above).
stereo_lit_vol
    This module assumes that a stereo ready monitor and viewing system
    (i.e.  StereoGraphics' Crystal Eyes) are available.  It will render
    a stereoscopic version of the disp_lit_vol module.  
    This module make use of a similar environment variable as the
    COMPUTE_SERVER variable used by the remote_volume module.  
    This module uses the environment variable STEREO_SERVER.  
    Set this variable to point at the stereo-ready device.  
    [In order to use this module well it is required that a second X
    display of some kind is available.]  Run AVS with the DISPLAY
    set to the non-stereo screen or server.  This module will open a
    full screen window on the display pointed to by STEREO_SERVER and
    will place the display in stereo mode (via the Starbase STEREO
    gescape).  Stereo mode can be toggled off and on with the "Stereo"
    control button. (Turn off the stereo mode before deleting this 
    module or exiting AVS, or your stereo display will be left in 
    stereo mode.) 
Have fun with these, (and drop me a line if you like them :-) .
--
Howard Stroyan
Hewlett-Packard
Advanced Systems Division / Graphics S/W Lab (ASD/GSL)     hstroyan@fc.hp.com
--------------------------- CUBIC_POLYPOINT MAN PAGE ------------------------
CUBIC_POLYPOINT 
 
The CUBIC_POLYPOINT gescape provides a means to specify points to be
rendered in a cubic volume specified in modeling coordinates.  For each
point specified by a data value, one pixel will be rendered (see
AUTO_FILL_VOXEL below).
 
The data may be provided in any orientation relative to the device
coordinate (DC) space.  This entrypoint sorts the data so as to always
render the points from back to front in the DC Z axis.  The data
specified is composited with the current contents of the framebuffer.
 
The compositing function is of the form:
 
     new value = (alpha * source) + ( (1 - alpha) * destination)
 
where source is the supplied value and destination is the current frame
buffer contents.  Compositing is performed separately for the red, green,
and blue banks.  This primitive assumes a 24-bit CMAP_FULL shade-mode (or
12/12 CMAP_FULL double-buffer).
 
This gescape does not support perspective transformations.
 
The arg2 parameter is ignored.
 
Input Parameters:
 
"ORIGIN: Start of the 1st scanline in the 1st slice"
arg1.f[0]           X value in Modeling coordinates
arg1.f[1]           Y value in Modeling coordinates
arg1.f[2]           Z value in Modeling coordinates
 
"End of the 1st scanline in the 1st slice"
arg1.f[3]           X value in Modeling coordinates
arg1.f[4]           Y value in Modeling coordinates
arg1.f[5]           Z value in Modeling coordinates
 
"Start of the last scanline in the 1st slice"
arg1.f[6]           X value in Modeling coordinates
arg1.f[7]           Y value in Modeling coordinates
arg1.f[8]           Z value in Modeling coordinates
 
"Start of the 1st scanline in the last slice"
 
arg1.f[9]           X value in Modeling coordinates
arg1.f[10]          Y value in Modeling coordinates
arg1.f[11]          Z value in Modeling coordinates
 
arg1.i[12]          Number of points per scanline to render
arg1.i[13]          Number of scanlines per slice to render
arg1.i[14]          Number of slices to render
arg1.i[15]          Number of voxels (data values) per point to skip
arg1.i[16]          Number of points per scanline to skip (at the end of
                    each line)
arg1.i[17]          Number of lines per slice to skip at end of each slice
arg1.i[18]          Vertex format flags
 
arg1.i[19]          Pointer to the data values (long words, packed bytes,
                    or packed shorts)
 
arg1.i[20]          Pointer to the data mapping table scalar(byte) ->
                    alpha,r,g,b (this parameter applies only to the
                    INDIRECT vertex formats)
 
The allowed values for the vertex format flag are:
 
NULL                Standard format is a pack word per voxel.  Each word
                    contains an byte of:  (alpha, red, green, blue) with
                    each byte scaled in the range of 0-255.
 
INDIRECT_DATA       Indicates that the vertex format is a packed byte
                    array of monotonic intensities which map into a 256
                    entry (alpha, red, green, blue) lookup table supplied
                    via a pointer in arg1.i[20].
 
INDIRECT_DATA16     Indicates that the vertex format is a packed short
                    (16 bit) array of intensity which maps into a 65,536
                    entry (alpha, red, green, blue) lookup table supplied
                    via a pointer in arg1.i[20].
 
PRE_SCALED_ALPHA    Indicates that the vertex format is per the
                    CRX-24/24Z's fast path (1-alpha, alpha*r, alpha*g,
                    alpha*b).  The CRX-24 will operate most efficiently
                    (quickly) if the direct data or indirect table is
                    pre-scaled as described here.  This pre-scaling will
                    avoid having the gescape scale the data per voxel
                    (for the DIRECT case) or per gescape (for the
                    INDIRECT case).
 
		    Note that the CRX-48Z and HCRX-24/24Z can directly
		    handle alpha, red, green, and blue.  For the CRX-48Z
		    and HCRX-24/24Z this option is slower and should not
		    be used, although it will still work.
AUTO_FILL_VOXEL     This flag enables a filling algorithm which will
		    render a rectangle for each voxel.  The rectangle
		    encloses the voxel cube projection and allows the DC
		    image to be enlarged without rarifying the
		    appearance of the rendered volume.  If this flag is
		    not present, a single pixel is modified per data
		    point, regardless of the DC spacing between data
		    points.