Use this routine to create a new RMpipe object for use with a specified display platform. Upon success, a handle to the new RMpipe object is returned to the caller, or NULL is returned upon failure.

The input parameter must be one of RM_PIPE_GLX, RM_PIPE_WGL, RM_PIPE_CR or RM_PIPE_NOPLATFORM. RM_PIPE_GLX specifies use on any X-based system that has the GLX extension (supports OpenGL through the server). RM_PIPE_WGL specifies use on a Win32 platform. RM_PIPE_CR specifies use only on a Chromium-enabled system. RM_PIPE_NOPLATFORM may be be used on any platform. The difference between RM_PIPE_NOPLATFORM and others is that some RMpipe fields are not initialized (swapbuffers function, context creation function,... ).

Note that RM_PIPE_GLX and RM_PIPE_WGL platforms can make use of Chromium as well for doing single application to one or more crservers. However, an RM_PIPE_CR platform is highly Chromium-specific. Refer to the RM Programming Guide for more details.

During rmPipeNew(), the RMpipe object is initialized with the following platform-specific and platform-neutral settings:

1. The "swapbuffers" function is set to a platform-appropriate value. The application may later override this setting using rmPipeSetSwapBuffersFunc(). By assigning a default swapbuffers function, we are assuming that the OpenGL context (created later) will be double buffered. For the RM_PIPE_NOPLATFORM, no swapbuffers function is assigned.

2. The "context creation function" is set to a platform-appropriate value. The application may indirectly override the context creation function using rmPipeSetContext() to assign an OpenGL context to the RMpipe. Such an assignment must occur between rmPipeNew() and rmPipeMakeCurrent().

3. The default channel format is RM_MONO_CHANNEL, which corresponds to an OpenGL visual that has RGBA color buffers, a depth buffer, and which is double-buffered. The channel format can be set using rmPipeSetChannelFormat() after rmPipeNew() returns, and before a window is created (or before drawing occurs in the case of RM_PIPE_CR).

4. The default processing mode is RM_PIPE_MULTISTAGE. This mode corresponds to serial rendering using a two-stage pipeline. You can set the processing mode after rmPipeNew() returns (see rmPipeSetProcessingMode), but before rmPipeMakeCurrent().

5. The "post render barrier function" is set to NULL (see rmPipeSetPostRenderBarrierFunc).

6. The "post render function" is set to NULL (see rmPipeSetPostRenderFunc).

7. Each of the following three passes of the multipass rendering engine is enabled by default: opaque 3D, transparent 3D, opaque 2D. Applications may not change the order of these rendering passes, but may enable or disable a given rendering pass with rmPipeSetRenderPassEnable().

The basic sequence of steps needed to fully initialize RM for rendering are:

1. Use rmPipeNew(yourPlatform) to create the RMpipe object specific for your platform.

2. Set any optional parameters on the RMpipe: processing mode (see rmPipeSetProcessingMode), channel format (see rmPipeSetChannelFormat), XDisplay on X systems (see rmxPipeSetDisplay).

X11 note: if you want to display somewhere other than getenv($DISPLAY), you will need to make an explicit call to rmxPipeSetDisplay() using an appropriate XDisplay structure. By default, rmPipeNew(RM_PIPE_GLX) will perform XOpenDisplay(getenv("$DISPLAY")), and assign the resulting XDisplay structure to the RMpipe. An opened X Display is necessary for access to bitmap fonts.

3. Create a window suitable for display. This can be done with either rmauxCreateXWindow() or rmauxCreateW32Window(), or a suitable drawable can be provided by an external source (for more details, see the RM Programming Guide).

4. Assign the window to the RMpipe (see rmPipeSetWindow)

5. Make the pipe current (rmPipeMakeCurrent).

Releases resources associated with an RMpipe object. This is the opposite of rmPipeNew(). Returns RM_WHACKED if the input RMpipe is NULL.

Use this routine to make a named RMpipe "active." Making an RMpipe "active" involves three primary processing stages. First, we take steps to either verify that an OpenGL context is current already, or we make current the OpenGL context assigned to the RMpipe. Second, we initialize the RMpipe's context cache. Third, we initialize some OpenGL variables needed by RM for rendering.

This routine will return a value of RM_CHILL to indicate that RM and OpenGL are ready for rendering. A value of RM_WHACKED is returned if either of the following is true: (1) RM was unable to initialize an OpenGL rendering context and/or make it current; (2) RM was unable to initialize its internal context cache and component manager. Both conditions (1) and (2) must be satisfied before rendering may occur. A return value of RM_WHACKED means that the RMpipe is not ready for use in rendering.

All applications will use this routine to make an RMpipe "active."

In the first stage of processing, we first check to see if there is an already "current" OpenGL context. If so, we do not disturb it, but just go ahead and use it. If no OpenGL context is already current, then we will attempt to make current the OpenGL context assigned to the RMpipe. This step requires the presence of a Window or HWND parameter in the X11 and Windows environments, respectively.

In the second stage of processing, this routine will check for the existance of an RMpipe "context cache," and will create a new one if one does not exist. If a context cache exists, it will be flushed and replaced with a new one.

The context cache is used internally by RM to store retained mode, OpenGL context-specific data, such as display list indices, texture object identifiers, and so forth. The reason for creating/replacing/activating the context cache in this routine, rather than earlier (when the OpenGL context is created) is due to the inconsistencies between X11 and Win32 in how OpenGL is initialized. In X11, the GLX context must be created prior to creating an X11 window (XCreateWindow needs an XVisualInfo structure, which reflects the pixel format chosen with glXChooseVisual). In Win32, the equivalent of an XVisualInfo structure is created using a window handle.

In nearly all applications, this routine will be called only once. It is not an error call it multiple times, but developers must be aware that any existing retained mode structures will be flushed by rmPipeMakeCurrent, and rebuilt during subsequent renderings.

This routine *must* be called by all applications between rmPipeNew() (RMpipe initialization) and rmFrame() (rendering).

This routine will destroy the OpenGL rendering context associated with the input RMpipe object, and delete all resources associated with the RMpipe's context cache, including all OpenGL display lists and texture object id's.

On X11, this routine will also close the X Display associated with the RMpipe.

Returns RM_CHILL upon success, or RM_WHACKED upon failure.

This routine will cause a buffer-swap on the display and window specified by the input RMpipe.

In the interest of speed, no error checking is performed inside this routine.

This routine is most typically called from within a rendering manager routine, and not directly from the application. There is nothing that precludes it's use directly by applications, if so desired.

Use this routine to set the "channel format" of an RMpipe object. Returns RM_CHILL upon success, or RM_WHACKED upon failure.

The RMpipe channel format serves two purposes. First, when multibuffered stereo is requested, this information must be known prior to creating an OpenGL rendering context. So, the channel format provides hints about the type of OpenGL capabilities that are needed by the application. As such, it is likely that the channel format interface will evolve over time to include more access to additional OpenGL capabilities.

Second, when a channel format is specified, internal to rmPipeSetChannelFormat(), an RM rendering callback is assigned to the pipe. The rendering callback knows about multipass rendering as well as how to instruct the underlying rendering engine in the details of managing stereo rendering.

This routine must be called between the time you create the RMpipe with rmPipeNew(), and before an OpenGL rendering context is created with rmPipeCreateContext(). It is a logic error to change an RMpipe's channel format after the OpenGL context has been created.

Returns to the caller the current channel format of an RMpipe object. A successful return value will be one of RM_MONO_CHANNEL, RM_REDBLUE_STEREO_CHANNEL, RM_BLUERED_STEREO_CHANNEL or RM_MBUF_STEREO_CHANNEL. A return value of RM_WHACKED indicates an error of some type.

By default, OpenRM will initialize the OpenGL matrix stack during a frame rendering operation by setting GL_MODELVIEW, GL_PROJECTION and GL_TEXTURE matrices to the Identity matrix. This behavior may be overridden, so that OpenRM will honor any existing matrices in the matrix stacks while accumulating nested transformations. This is helpful in some deployment environments, such as combining OpenRM with CAVElib (www.vrco.com).

When the input enumerator is set to RM_TRUE (the default), OpenRM will initialize the OpenGL matrix stack to the identity matrix prior to accumulating transformations during rendering. When the input enum is set to RM_FALSE, OpenRM will NOT initialize the matrix stack, and any existing transformations within the scene graph will be accumulated with the contents of the matrix stack at render time.

More precisely, if the GL_MODELVIEW matrix stack has the matrix M, and the scene graph defines a matrix transformation S, the combined transformation will be S*M (left multiplication), so that the scene graph transformation S is effectively applied prior to the outer transformation M when vertex data moves down the OpenGL transformation pipeline.

Returns RM_CHILL upon success, or RM_WHACKED upon failure.

This routine will return the "init matrix stack" attribute of an RMpipe object. A return value of RM_TRUE means the OpenGL matrix stack will be initialized by OpenRM during frame rendering, while a value of RM_FALSE means that any existing values in the OpenGL matrix stack will be honored during rendering.

A return value of RM_WHACKED indicates an error condition.

This routine is used to selectely enable or disable one of the rendering passes of the RM multipass rendering engine. Applications may not change the order of the rendering passes, but may selectively enable or disable a given pass. The order of the passes is:

1. 3D Opaque

2. 3D Transparent

3. 2D Opaque

(There may be a 2D transparent pass in a later release.)

During each of these passes, traversal filters are applied at each node of the RM scene graph. If, at any stage during the traversal, the scene graph node does not pass the traversal filter test, that node, and any descendents, are not processed.

For this reason, developers should carefully consider scene graph design such that 3D opaque, 3D transparent and 2D objects are appropriately partitioned within the scene graph itself.

Background scene operations (background clear color, background image tile, background depth value, background depth image) are performed during rendering passes 1 and 3. A common RM error is to place a background scene operation at a node that is processed during multiple rendering passes.

Returns RM_CHILL upon success, or RM_WHACKED upon failure.

This routine is used to obtain the boolean values that indicate if a particular rendering pass is enabled in the RMpipe.

Each of the return parameters is optional - a value of NULL will skip reporting of that particular rendering pass.

Upon success, RM_CHILL is returned, and RM_TRUE or RM_FALSE is copied into non-NULL caller-supplied memory for each of the RMpipe rendering passes. Otherwise, RM_WHACKED is returned, and caller-supplied memory remains unmodified.

This routine sets the RMpipe's notion of pixel width and height of it's associated display window. RM_CHILL is returned upon success, or RM_WHACKED upon failure.

The most typical use of this routine will be when an application detects, through an event loop, that the window geometry has changed. The application is reponsible for notifying RM of such changes; RM doesn't manage events and doesn't keep track of the size of the display window.

This routine is called by rmPipeSetWindow().

This routine returns via caller-supplied memory the named RMpipe's notion of the current window width and height. RM_CHILL is returned upon success, or RM_WHACKED upon failure.

Callers interested in only width or height may specify NULL for the parameter for which information is not requested.

Use this routine to set the "swapbuffers" callback function associated with an RMpipe object. Returns RM_CHILL upon success, or RM_WHACKED upon failure.

The swapbuffers function is invoked after rendering has completed, and after the post-render barrier function, and the post-render framebuffer and depthbuffer grab callbacks, if any. By default, rmSwapBuffers() is assigned to all RMpipe objects' swapbuffers callback functions at the time the RMpipe is created with RMpipe new. The function rmSwapBuffers() calls the native window-system procedure that causes front and back buffers to be swapped.

If the application overrides the default swapbuffers function, the application callback will be provided a single input parameter: a handle to an RMpipe object. The RMpipe object contains enough information to enable application code to do the swapbuffers call.

This routine assigns a "post render" application callback to the RMpipe. The post render callback is invoked after rendering has occured, and after the "post render barrier function" has been called (if any), but before the "post render depthbuffer function" (if any) and before the swapbuffers function. RM_CHILL is returned upon success, or RM_WHACKED upon failure.

Use a value of NULL for the postRenderFunc to effectively disable post rendering callbacks.

The purpose of the post render function is to allow applications to grab a copy of the color planes of the framebuffer after rendering has occured. If you want the raw image data produced by the rendering, this is the path to use.

When the application callback is invoked, the callback is invoked with two parameters. The first is a handle to an RMimage object. Use rmImageGetPixelData() to obtain the raw pixel data from this image. At this time (Jan 2000) the image provided to the app callback is in GL_RGBA, GL_UNSIGNED_BYTE format. Applications are advised to use the rmImageGet*() series of routines to obtain RMimage configuration information. In particular, pay close attention to scanline-padding issues.

The second parameter provided to the application callback is an RMenum value that is one of RM_ALL_CHANNELS, RM_LEFT_CHANNEL or RM_RIGHT_CHANNEL. Multibuffered stereo channels will invoke the application callback twice, once for each channel. Anaglyph stereo formats (RM_REDBLUE_STEREO_CHANNEL and RM_BLUERED_STEREO_CHANNEL) will trigger the callback just once. This may change in the future (Jan 2000).

The RMimage object provided to applications is managed by RM.

Use this routine to assign a "post render depth buffer" callback to an RMpipe object. RM_CHILL is returned upon success, or RM_WHACKED upon failure.

Use a value of NULL for the postRenderDepthFunc to effectively disable this post rendering callback.

Whereas the "post render callback" gives applications access to the color planes of the framebuffer after rendering, the purpose of this callback is to give applications access to the depth buffer after rendering has completed. Assigning a "post render depth buffer callback" will cause the application callback to be invoked after rendering, and after the post-render barrier function, after the post render callback (the color planes) but before the swapbuffers function.

The pixel data of the RMimage object provided to the application, the first application callback parameter, contains the contents of the depth buffer of the scene just rendered. The pixel data in the RMimage object is in RM_FLOAT format. Applications should use the rmImageGet*() series of routines to query specific RMimage attributes.

The second parameter provided to the application callback is an RMenum value that is one of RM_ALL_CHANNELS, RM_LEFT_CHANNEL or RM_RIGHT_CHANNEL. Multibuffered stereo channels will invoke the application callback twice, once for each channel. Anaglyph stereo formats (RM_REDBLUE_STEREO_CHANNEL and RM_BLUERED_STEREO_CHANNEL) will trigger the callback just once. This may change in the future (Jan 2000).

The RMimage object provided to applications is managed by RM.

Use this routine to set the "post render barrier function" on an RMpipe object. Use a value of NULL for barrierFunc to disable this callback, or remove a previously installed callback. Returns RM_CHILL upon success, or RM_WHACKED upon failure.

The "post render barrier" callback, if present, will be invoked immediately after rendering, but prior to any other callbacks (post render color planes callback, post render depth buffer callback or swapbuffers). This routine is intended for use by parallel rendering applications.

The application callback will be provided a single parameter, an RMpipe.

This routine can be used to determine if the processing mode of the RMpipe toQuery is a multithreaded format. If toQuery's processing mode is either RM_PIPE_MULTISTAGE_VIEW_PARALLEL or RM_PIPE_MULTISTAGE_PARALLEL, this routine will return RM_TRUE. Otherwise, RM_FALSE is returned.

See also rmPipeGetProcessingMode().

This routine will return the processing mode of the RMpipe toQuery. Upon success, one of the following is returned to the caller: RM_PIPE_SERIAL, RM_PIPE_MULTISTAGE, RM_PIPE_MULTISTAGE_PARALLEL or RM_PIPE_MULTISTAGE_VIEW_PARALLEL.

Upon failure, RM_WHACKED is returned to the caller.

This routine will select the "processing mode" for an RMpipe object. The processing mode assigns a rendering engine to the RMpipe for use in subsequent rendering operations. Upon success, RM_CHILL is returned to the caller; upon failure, RM_WHACKED is returned.

Applications may set the processing mode on an RMpipe any time between when it is created (using either rmPipeNew or rmPipeInit) and the first time a frame is rendered. As of this time (June 2001), it is not possible to change the processing mode of an RMpipe, and this routine will not detect this error condition. Your application will likely crash if you attempt to alter the processing mode of an RMpipe after the first frame has been drawn.

OpenRM uses a two-stage rendering pipeline: a view traversal of the scene graph prepares a list of things to be drawn during a rendering traversal.

The following processing modes are supported:

RM_PIPE_MULTISTAGE - uses a two-stage rendering traversal (view, render), and both stages are called sequentially within the same process/thread as the caller. There is no parallelization in this processing mode.

RM_PIPE_MULTISTAGE_PARALLEL - each of the two rendering stages are called from detached Posix threads. The render thread will assume ownership of the OpenGL context (applications should NOT make any OpenGL calls except from within node callbacks invoked by the OpenRM renderer). This mode is fully parallelized.

RM_PIPE_MULTISTAGE_VIEW_PARALLEL - the view traversal is assigned to a detached thread, while the render traversal remains in the same execution process/thread as the caller (and does not attempt to exert ownership of the OpenGL rendering context). This mode is also fully parallelized, and is quite useful when combining OpenRM with other toolkits that provide device and event management and which make assumptions about ownership of the OpenGL rendering context (e.g., CAVELibrary, VRJuggler, FLTK, etc.).

This routine will return the RMpipe's notion of whether or not it will use OpenGL display lists when rendering primitives. The returned value will be either RM_TRUE, which indicates that display lists will be used when rendering primitives on the RMpipe, or RM_FALSE, which indicates that no RMprimitives will be drawn using display lists.

See also: rmPipeSetDisplayListEnable, rmPrimitiveSetDisplayListEnable.

Set's the RMpipe's policy on the use of display lists. When the value of newMode is set to RM_TRUE, use of display lists on the RMpipe toModify is enabled. When set to RM_FALSE, use of display lists on the RMpipe is disabled. The default policy for use of display lists is RM_TRUE, and this value is set at the time the RMpipe is created. You can override the default behavior by calling rmPipeSetDisplayListEnable() with a value of RM_FALSE.

Use of display lists can greatly accelerate rendering performance on many platforms. By default, RM will attempt to create display lists for RMprimitives during rendering, and reuse them in subsequent renderings.

Applications can control use of display lists in two ways: at the RMpipe level, and at the RMprimitive level. At the RMpipe level, you can enable or disable use of display lists for all RMprimitives drawn on RMpipe using the routine rmPipeSetDisplayListEnable. At the RMprimitive level, you can enable or disable the use of display lists for a single primitive using rmPrimitiveSetDisplayListEnable().

The RMprimitive display list policy does not override the display list policy set at the RMpipe level. In other words, if the policy at the RMpipe level is set to RM_FALSE, then no display lists will be used, even if the policy at the RMprimitive level is set to RM_TRUE. On the other hand, if the policy at the RMpipe level is set to RM_TRUE, a policy at the RMprimitive level of RM_FALSE will result on no display lists being used for the one RMprimitive. In order for display lists to be used at any given RMprimitive, the logical AND of RMpipe and RMprimitive display list policies must be RM_TRUE.

To obtain the current display list use policy at an RMpipe, use the routine rmPipeGetDisplayListEnable().

See also rmPrimitiveSetDisplayListEnable().

Sets the global number of PEs in an MPI-parallel application. Docs need to be better written.

Returns the global number of PEs in an MPI-parallel application. Docs need to be better written.

Sets the rank value of one RMpipe in an MPI-parallel application. Docs need to be better written.

Obtains the rank value of one RMpipe in an MPI-parallel application. Docs need to be better written.

Returns to the caller a character string defining $DISPLAY, the display name. $DISPLAY has an effect only on GL_PIPE_GLX platforms.

Use this routine to set the $DISPLAY variable in an RMpipe. This variable is used only on RM_PIPE_GLX platforms, and only when a Returns to the caller a character string defining $DISPLAY, the display name. $DISPLAY has an effect only on GL_PIPE_GLX platforms.

Returns to the caller the X Display handle, cast to void *, associated with an RMpipe.

This routine is used to specify the desired frame rate when rendering on the RMpipe toModify. The caller provides an integer value, newFPS, that indicates the desired number of frames per second. A value of 30 will result in 30 frames per second being rendered, etc. A value of -1 will disable constant-rate rendering: OpenRM will not "watch the clock" if you specify a value of -1 frames per second as the desired target rate. The value for newFPS should be a positive integer. Note that not all values of newFPS make sense on all platforms for reasons related to how OpenGL is implemented on your machine.

Constant-rate rendering is really a misnomer : what the contstant-rate rendering capability in OpenRM really does is to use a high precision timer and sleep function to ensure that *no more than a given number of frames per second are rendered*. In this way, you can be assured that your application will not be rendering more than newFPS per second. If your application produces a heavy graphics load, the actual rendering rate may fall well short of newFPS frames per second. Rather than calling this capability "constant frame rate" rendering, it is more accurately called "bounded frame rate" rendering.

Future work in this area will result in the ability for the application to query the rendering "load" or "stress" values. This way, you'll be able to obtain a quantitative value that indicates how far "over budget" your rendering is, and take action accordingly. One remedial action will be for the application to use switch nodes and render lower-resolution models as a way to reduce graphics rendering load.

From the newFPS parameter, a value of milliseconds-per-frame is computed. When your application calls rmFrame() for the first time, OpenRM makes note of the current time. It then proceeds with rendering without delay, and then returns control to the application after rendering is complete. The second time your application calls rmFrame(), OpenRM will delay rendering so that the time taken by rendering during the previous frame along with the time taken by the application for processing inbetween frames does not exceed the occur before the milliseconds-per-frame amount of time has passed. In other words, the period of timing is from the start of rendering to the start of rendering.

The bounded-frame-rendering capability works on both Unix/Linux and Win32 platforms subject to caveats that are described in the OpenRM Programming Guide. Additional caveats not specific to a platform are also discussed in the OpenRM Progamming Guide.

Use the routine rmPipeGetFrameRate() to query the frames-per-second parameter of an RMpipe.

Returns RM_CHILL upon success, or RM_WHACKED upon failure.

Use this routine to obtain the RMpipe's notion of how many frames per second it is supposed to render. For a more meaningful discussion of what the frames-per-second RMpipe attribute means, refer to the discussion for rmPipeSetFrameRate() as well as the OpenRM Programming Guide.

Returns either -1 or a positive integer on success, or zero on failure.

Use this routine to obtain the RMpipe's notion of the current frame number. Upon success, a non-negative integer is returned. Upon failure, a value of -1 is returned.

The RMpipe's frame number is initialized to zero when the RMpipe is created with rmPipeNew(). Upon each call to rmFrame(), the the frame number is incremented by one. There is no mechanism for applications to set the frame number, or for applications to reset the frame number to zero.

Use this routine to obtain the number of OpenGL multitexturing units available from the underlying OpenGL implementation. This routine returns the following values:

-1 is used to indicate an error of some type, like if the input RMpipe is NULL.

0 (zero) is returned if the underlying OpenGL platform does not support multitexturing.

>0 (positive integer) is returned to indicate the number of usable OpenGL multitexture units. Note that the number of texture units is implementation dependent, but should be at least two when multitexturing is present.

This routine should be called only after the input RMpipe has been subjected to successful call to rmPipeMakeCurrent.

In RM/OpenRM, you may set a "background color" scene parameter at the RMnode level, at the RMpipe level, or both. The background color may consist of a single color or a color background image. In addition, you may also set a depth value or a depth image that will be used to initialize the z-buffer. The main issue with assigning a background color/depth parameter at the RMnode vs. the RMpipe level is convenience vs. fine-grained control. If you assign the background color/depth value at the RMpipe level, the background will be cleared once each time your application calls rmFrame() to render a scene. In some cases, such as when multiple viewports are rendered within a single window with a single call to rmFrame(), then you must assign the background color/depth value at the RMnode level. Unlike when assigning such values at the RMpipe level, using them at the RMnode level requires special care due to the multiple rendering passes RM makes for a single call to rmFrame(). The RMnode containing the background color/depth values must have its traversal mask set such that it is invoked at most once per call to rmFrame().

Use rmPipeSetSceneBackgroundColor to set the background color scene parameter at the RMpipe level. Calling this routine with a color argument of NULL disables the background color scene parameter. During rendering, the color planes of the framebuffer are cleared to this background color (with a depth value of 1.0, see NOTE below).

Upon success, RM_CHILL is returned and the specified background color scene parameter is set. Otherwise, RM_WHACKED is returned, and the background color scene parameter remains unmodified.

Passing in a value of NULL for the RMcolor4D object will effectively remove any existing background image color parameter from the RMpipe toModify.

NOTE: internal to this routine, a call to rmPipeSetSceneDepthValue is performed, effectively coupling framebuffer and depthbuffer clears.

Because this routine makes a copy of the input scene parameter (an RMcolor4D object), callers do not need to manage the input object after a successful return from this routine. This has important ramificiations:

1. Since a copy is made, any changes made to the caller's object will have no effect upon the scene graph, unless this routine is called again to update the scene parameter inside the scene graph;

2. Callers may safely delete their copy of the input object after a successful return from this routine.

Related routines: rmPipeGetSceneBackgroundColor, rmPipeSetSceneBackgroundImage, rmPipeSetSceneDepthValue.

Use this routine to obtain the background color scene parameter of an RMpipe, if such a scene parameter exists.

Upon success, RM_CHILL is returned and the scene background color is copied into the caller-supplied RMcolor4D (effectively returning a copy of the background color scene parameter to the caller). If no such scene parameter exists, or if there is some error condition detected, RM_WHACKED is returned, and the caller-supplied colorReturn object remains unmodified.

In RM/OpenRM, you may set a "background color" scene parameter at the RMnode level, at the RMpipe level, or both. The background color may consist of a single color or a color background image. In addition, you may also set a depth value or a depth image that will be used to initialize the z-buffer. The main issue with assigning a background color/depth parameter at the RMnode vs. the RMpipe level is convenience vs. fine-grained control. If you assign the background color/depth value at the RMpipe level, the background will be cleared once each time your application calls rmFrame() to render a scene. In some cases, such as when multiple viewports are rendered within a single window with a single call to rmFrame(), then you must assign the background color/depth value at the RMnode level. Unlike when assigning such values at the RMpipe level, using them at the RMnode level requires special care due to the multiple rendering passes RM makes for a single call to rmFrame(). The RMnode containing the background color/depth values must have its traversal mask set such that it is invoked at most once per call to rmFrame().

rmPipeSetSceneBackgroundImage sets the background image scene parameter for the RMpipe. When rendered, this image is tiled into the viewport at the scene depth value (or a default of 1.0) with an orthogonal projection, creating a background image. If the image does not fit the display, it will be tiled from top to bottom and left to right, so ragged edges fall on the bottom and right edges of the viewport.

Passing in a value of NULL for the newImageTile parameter will effectively remove the background image tile scene parameter, if it exists.

Upon success, RM_CHILL is returned and the background image scene parameter has been modified. Otherwise, RM_WHACKED is returned.

Because this routine makes a copy of the input scene parameter (an RMimage object), callers do not need to manage the input object after a successful return from this routine. This has important ramificiations:

1. Since a copy is made, any changes made to the caller's object will have no effect upon the scene graph, unless this routine is called again to update the scene parameter inside the scene graph;

2. Callers may safely delete their copy of the input object after a successful return from this routine.

NOTE: internal to this routine, a call to rmPipSetSceneDepthValue() is performed, effectively coupling framebuffer clears (by image tiling) with depth buffer clears.

Use this routine to obtain the background image scene parameter of an RMpipe. Note that a handle to the RMimage is returned, not a copy of the actual pixel data.

Upon success, RM_CHILL is returned and a handle to the scene background image is copied into the caller-supplied RMimage handle. Otherwise, RM_WHACKED is returned.

Unlike most other rmPipeGetScene*() routines, this routine returns a handle to the actual object contained within the RMpipe, rather than returning a copy. Applications should exercise appropriate discretion when using this object.

In RM/OpenRM, you may set a "background color" scene parameter at the RMnode level, at the RMpipe level, or both. The background color may consist of a single color or a color background image. In addition, you may also set a depth value or a depth image that will be used to initialize the z-buffer. The main issue with assigning a background color/depth parameter at the RMnode vs. the RMpipe level is convenience vs. fine-grained control. If you assign the background color/depth value at the RMpipe level, the background will be cleared once each time your application calls rmFrame() to render a scene. In some cases, such as when multiple viewports are rendered within a single window with a single call to rmFrame(), then you must assign the background color/depth value at the RMnode level. Unlike when assigning such values at the RMpipe level, using them at the RMnode level requires special care due to the multiple rendering passes RM makes for a single call to rmFrame(). The RMnode containing the background color/depth values must have its traversal mask set such that it is invoked at most once per call to rmFrame().

rmPipeSetSceneDepthImage assigns a depth image as a scene parameter for the input RMpipe toModify. The depth image is similar to the background image tile, but is applied to the depth buffer, rather than the color planes of the framebuffer. Like the background image tile, the depth image scene parameter is tiled to fill the framebuffer, starting from the upper left-hand corner of the viewport. If the size of the depth buffer image and viewport do not match exactly, the "ragged edges" or on the right and the bottom of the viewport.

Passing in a value of NULL for the RMimage object will have the effect of removing the background depth image scene parameter, if one exists, from the RMnode.

Upon success, a copy of the caller's RMimage object is made, and the copy is assigned as a scene parameter (or, if the input RMimage object is NULL, the NULL is assigned as a depth image scene parameter, effectively turning off that scene parameter), and RM_CHILL is returned; otherwise, RM_WHACKED is returned.

Because this routine makes a copy of the input scene parameter (an RMimage), callers do not need to manage the input object after a successful return from this routine. This has important ramificiations:

1. Since a copy is made, any changes made to the caller's object will have no effect upon the scene graph, unless this routine is called again to update the scene parameter inside the scene graph;

2. Callers may safely delete their copy of the input object after a successful return from this routine.

Note: as a practical matter, it is suggested that the pixel format of input RMimage objects should be of type RM_FLOAT, and in the range 0..1. By default, depth buffer Pixels in OpenGL range from 0..1 (or perhaps 0..0.9999, depending upon your interpretation), but this range may be manipulated with glPixelTransferf(). As of the time of this writing (May 2000), we have tested background depth images only with RMimage's consisting of RM_FLOAT pixels in the range 0..1 (and they work - refer to the demonstration program "pdb" included with the openrm-demo distribution).

Use this routine to obtain the RMpipe's depth image scene parameter. If such a scene parameter exists, the handle of the RMimage (depth image) scene parameter is copied into caller-supplied memory, and RM_CHILL is returned. Otherwise, in the event of an error or the absence of the depth image scene parameter, RM_WHACKED is returned and caller supplied memory remains unmodified.

Unlike most other rmPipeGetScene*() routines, this routine returns a handle to the actual RMimage object contained within the scene graph, rather than returning a copy. Applications should exercise appropriate discretion when using this object.

In RM/OpenRM, you may set a "background color" scene parameter at the RMnode level, at the RMpipe level, or both. The background color may consist of a single color or a color background image. In addition, you may also set a depth value or a depth image that will be used to initialize the z-buffer. The main issue with assigning a background color/depth parameter at the RMnode vs. the RMpipe level is convenience vs. fine-grained control. If you assign the background color/depth value at the RMpipe level, the background will be cleared once each time your application calls rmFrame() to render a scene. In some cases, such as when multiple viewports are rendered within a single window with a single call to rmFrame(), then you must assign the background color/depth value at the RMnode level. Unlike when assigning such values at the RMpipe level, using them at the RMnode level requires special care due to the multiple rendering passes RM makes for a single call to rmFrame(). The RMnode containing the background color/depth values must have its traversal mask set such that it is invoked at most once per call to rmFrame().

Use rmPipeSetSceneDepthValue to set the scene depth value parameter for an RMpipe. The presence of the scene depth value has the effect of clearing the depth buffer to the value of newDepthValue.

Passing in a value of NULL for newDepthValue has the effect of disabling depth buffer clears.

The input newDepthValue should have the magnitude specified by glPixelTransferf(GL_DEPTH_SCALE,X) and range specified by glPixelTransferf(GL_DEPTH_BIAS,X). In OpenGL, the default depth bias is 0.0 and range/scale is 1.0.

Upon success, RM_CHILL is returned and the node's depth value is set. Otherwise, RM_WHACKED is returned.

Use this routine to query the scene depth value for a given RMpipe.

Upon success, RM_CHILL is returned and the node's depth value is copied into the caller-supplied float. If the specified pointers are NULL, or no valid scene depth parameter exists, RM_WHACKED is returned.