This program creates four quads that have a false-colored texture applied. The four quads, displayed using an RMcamera2D (2D camera), will rotate 360 degrees about the Z-axis over the course of 18 (or maybe 36) frames. The program uses some OpenRM routines to initialize the RMpipe, but then all rendering is done using raw OpenGL calls. The purpose of this program is to test the pixeltransfer pipeline in Chromium.
[-bbox (0|1) ] // turn on or off use of GL_OBJECT_BBOX_CR. Default is off.
This program can be run as a serial program, or with two-way parallelism. E.g., mpirun -np 1 <programName> or mpirun -np 2 <programName>
|
|
This program creates four quads that have separate textures applied to each quad. The quads are displayed using an RMcamera2D (2D camera), and rotate 360 degrees about the Y-axis over the course of 18 (or maybe 36) frames. Some OpenRM routines are used to initialize the RMpipe and to read/manage image data, but rendering is performed using raw OpenGL. multi-display environments.
[-bbox (0|1) ] // turn on or off use of GL_OBJECT_BBOX_CR. Default is off.
This program can be run as a serial program, or with two-way parallelism. E.g., mpirun -np 1 <programName> or mpirun -np 2 <programName>
|
This program creates four quads that have separate textures applied to each quad. The quads are displayed using an RMcamera2D (2D camera), and rotate 360 degrees about the Y-axis over the course of 18 (or maybe 36) frames. OpenRM is used for all aspects of this application - initialization, data management and rendering. to read/manage image data, but rendering is performed using raw OpenGL. The purpose of this program is to test survival of texture objects in multi-display environments, as well as exercise the interaction between OpenRM's texture management facility, the component manager and Chromium.
[-dlist ( 0 | 1 )] // turn on or off global use of display lists (default is to NOT use display lists to avoid Chromium display list bugs). Use of display lists == use of GL_OBJECT_BBOX_CR.
This program can be run as a serial program, or with two-way parallelism. E.g., mpirun -np 1 <programName> or mpirun -np 2 <programName>
|
|
This program performs data-parallel isocontouring. It uses OpenRM's isocontouring code to generate triangles from data, stores data in OpenRM's scene graph and uses OpenRM for all rendering. The purpose of this program is to exercise data-parallel operations, and parallel graphics stream submission in Chromium, including use of display lists. The entire 3D model is rotated 360 degrees about the Y-axis over the course of 18 frames.
[-i inputDataFileNameString] // set the input volume file name. default is data/blocks-config [-l isoContourLevelFloat] // set the isocontouring level [-t initialTimeStepOffsetInt] // set the initial timestep index, default is zero [-dlist ( 0 | 1 )] // turn on or off global use of display lists (default is to NOT use display lists) [-boxes ( 0 | 1 )] // turn on or off creation of outline boxes for each block (default is to create such boxes)
None. You can run this program with arbitrary levels of parallelism. The per-PE colors are set up to accommodate up to eight unique per-PE colors. After 8 parallel application nodes, the colors start to repeat.
|
This program creates a number of transparent 3D quads whose color and transparency is a function of parametric location within a unit cube. Over the course of 18 frames, the entire model rotates 360 degrees about the Y-axis. The purpose of this program is to test the implementation of an inter-PE sorting algorithm used for view-dependent back-to-front sorting in distributed memory parallel environments.
[-n N] // set the number of divisions along each axis, produces N^3 blocks [-s (0|1) // turn on or off transparency sorting. default is on.
None. You can run this program with arbitrary levels of parallelism.
|
This program performs sort-first parallel volume rendering. Each application PE reads in a subset of some scientific data, constructs 3D textures and octmesh primitives for each data block, and then rotates the entire model 360 degrees about the Y axis over the course of 18 frames. The numerous command line arguments are used to exercise various paths through the pixel pipeline. -rgba 1 works the best, as pixel transfer causes texture broadcasts from tilesort. This program uses the same distributed memory inter-PE sorting algorithm described in sortTest.
[-i inputDataFileNameString] // set the input volume file name. default is data/blocks-config [-t initialTimeStepOffsetInt] // set the initial timestep index, default=zero [-c // colorize data using pixeltransfer. default is grayscale ] [-s (0|1) // turn on or off inter-PE sorting. default is on. ] [-rgba (0|1) // says to use RGBA texture format, rather than LUM_ALPHA]. Default is to use LUM_ALPHA. May be combined with -c. [-pal fname // use the color palette in 'fname' rather than the default hue ramp when colorizing data. the palette file is 256 bytes of R, 256 bytes of G, 256 bytes of B and 256 bytes of A.] [-bbox (1|0) // turn on or off generation of octmesh CR bboxes, default is 1] [-dlist ( 0 | 1 )] // turn on or off global use of display lists (default is to NOT use display lists) [-boxes (1|0) // turn on or off the outline box geometry. default is 1]
None. You can run this program with arbitrary levels of parallelism.
|
|
| This image was created with no command line arguments. | This image was created only using the "-c" command line argument. |
|
|
| This image was created using the command line arguments "-rgba 1 -pal data/vrendPalette" |
This program is logically equivalent to vrendBlocksMPI, but supports distance-based level-of-detail (LOD) model switching. For each 3D texture, a reduced resolution texture is computed and used as the alternate model. Blocks "close to" the viewer are rendered using the full resolution 3D texture, while blocks "far away" from the viewer are rendered using reduced resolution models. There is no command-line control over the distance range used for model switching. Internal to the application, the LOD switchover distance is computed to be the average of the distances to the center point of all data blocks.
[-i inputDataFileNameString] // set the input volume file name. default is data/blocks-config [-t initialTimeStepOffsetInt] // set the initial timestep index, default=zero [-c // colorize data using pixeltransfer. default is grayscale ] [-s (0|1) // turn on or off inter-PE sorting. default is on. ] [-rgba (0|1) // says to use RGBA texture format, rather than LUM_ALPHA]. Default is to use LUM_ALPHA. May be combined with -c. [-pal fname // use the color palette in 'fname' rather than the default hue ramp when colorizing data. the palette file is 256 bytes of R, 256 bytes of G, 256 bytes of B and 256 bytes of A.] [-bbox (1|0) // turn on or off generation of octmesh CR bboxes, default is 1] [-boxes (1|0) // turn on or off the outline box geometry. default is 1] [-dlist ( 0 | 1 )] // turn on or off global use of display lists (default is to NOT use display lists) [-lod (1|0) // turn on or off the LOD stuff. default is 1] [-fake // do LOD switching, but use a "fake" texture, useful for debug]
None. You can run this program with arbitrary levels of parallelism.
Internal to the application are several #defines you may modify to alter program behavior. They are as follows:
|
|
| Command line args: vrendBlocksMPI-LOD -c | Command line args: vrendBlocksMPI-LOD -c -fake |
|
|
| Command line args: vrendBlocksMPI-LOD -rgba 1 -pal data/vrendPalette | Command line args: vrendBlocksMPI-LOD -rgba 1 -pal data/vrendPalette -fake |
This program is logically equivalent to vrendBlocksMPI-LOD, but is implemented so as to support interactive use employing the "standard UI model" present in the OpenRM demo programs. This program does not use Chromium, and should be run serially (no parallelism).
[-i inputDataFileNameString] // set the input volume file name. default is data/blocks-config [-t initialTimeStepOffsetInt] // set the initial timestep index, default=zero [-c // colorize data using pixeltransfer. default is grayscale ] [-s (0|1) // turn on or off inter-PE sorting. default is on. ] [-rgba (0|1) // says to use RGBA texture format, rather than LUM_ALPHA]. Default is to use LUM_ALPHA. May be combined with -c. [-pal fname // use the color palette in 'fname' rather than the default hue ramp when colorizing data. the palette file is 256 bytes of R, 256 bytes of G, 256 bytes of B and 256 bytes of A.] [-bbox (1|0) // turn on or off generation of octmesh CR bboxes, default is 1] [-boxes (1|0) // turn on or off the outline box geometry. default is 1] [-lod (1|0) // turn on or off the LOD stuff. default is 1]
This program was intended to be run serially - one-way parallelism. The reason is because this program supports interactive transformations. Also, it creates a window on an RM_PIPE_GLX pipe, not a Chromium-specific pipe.
The Makefile build target for this application is purposefully commented out. In order to build this program, you have to take steps to link with a non-Chromium build of OpenRM. This isn't a problem; the problem is in having Chromium and non-Chromium enabled versions of OpenRM on your system. For example, you can have the Chromium-enabled version of OpenRM installed in /usr/local/rm151/lib-CR, and the non-Chromium version located in /usr/local/rm151/lib-noCR, and then create a symlink from /usr/local/rm151/lib to whichever directory is desired. This approach works, but is something of an annoyance. To minimize annoyance, we have just commented out the build target. You can add it back in if you want and are willing to endure a small bit of annoyance.
A number of Chromium configuration files are located in the rmdemoCR/confs directory, and are intended to be used with these applications. There are four files, each of which assumes a slightly different configuration of number of application PEs and Chromium display servers. The filenames for the four configuration files are self-explanatory.
When you use one of the files whose name begins with "fourAppNodes*", you must launch the rmdemoCR demo program using 4-way parallelism, e.g., "mpirun -np 4 <programName>". When you use one of the files whose name begins with "oneAppNode*", you must run the rmdemoCR program as a serial job. All configuration files use the "autostart" feature to launch Chromium servers.
All configuration files are set up to use "localhost". The configuration files all rely on "rsh" to launch jobs, so make sure that you have passwordless rsh logins permitted, otherwise parallel jobs won't work for you. Lack of security is a known weakness in the Chromium execution model.
Chromium configuration files are really Python programs, so you launch them by running them as python jobs. Your primary source of documentation for managing Chromium jobs is the Chromium project itself. Please make sure that you can run the demo programs that accompany Chromium prior to trying to run the OpenRM+CR demo programs. The Chromium documentation is located at http://chromium.sourceforge.net/.
The rmdemoCR distribution contains a subdirectory named rmdemo-confs, which contains four configuration files to be used when running the regular OpenRM demo programs in a Chromium environment. Since all the regular OpenRM demo programs are serial, your choices are somewhat more limited than with the parallel OpenRM+CR demo programs. The four rmdemo-conf files achieve the following objectives (the filenames are self-explanatory):
As of the time of this writing (11 Aug 2005), we are using version 1.0-76.67 of the Nvidia Linux OpenGL drivers and have no problems with any of the applications.
As of the time of this writing (11 Aug 2005), we have tested against version 1.8 of Chromium (March 2005) and all the demo programs operate correctly.
More information about the blocks format will be forthcoming. For now, you
can find more information
on this web page.
|
This page last modified
Thursday, 11-Aug-2005 07:23:07 PDT
Web problem or question? Send email to webmazen at r3vis.com |