OpenRM Scene Graph is a scene graph API that implements fully piplined-parallelized multistage and multithreaded rendering, and uses OpenGL as a graphics platform for hardware acceleration. A scene graph model is a useful way to organize data for rendering in a way that is particularly efficient for graphics display engines. The reason you might want to use a scene graph API for development is because you can reuse code and ideas, and benefit from others' work in the area of detailed graphics platform programming. In other words, a scene graph API is a framework for building graphics applications, and since all graphics applications need some sort of similar framework, you, as a developer, benefit from the OpenRM framework.

The ultimate goals of OpenRM include high performance rendering, a full-featured scene graph model, flexibility and extensibilty.

A list of OpenRM features reads like a marketing data sheet, but here are the high points:

• Support for application-supplied OpenGL texture object and display list identifiers.
• Multitexturing support.
• Support for distributed memory parallel applications when combined with Chromium. This feature is particularly useful for running parallel graphics and visualization applications on Linux clusters equipped with high performance commodity graphics hardware.
• Full multistage and multithreaded (parallel) rendering implemented on Unix/Linux/Win32.
• Support for precision, constant-rate rendering on Unix/Linux/Win32.
• Full support for hardware accelerated offscreen rendering on Unix/Linux, and for offscreen OpenGL (DIB) rendering on Win32.
• Image loader/writer support for JPEG and PPM formats.
• Rich lighting environment and light sources, including support for OpenGL spotlights.
• Atmospheric effects via OpenGL fogging.
• Rich texturing environment, including support for 1D, 2D and 3D textures.
• Thread-safe scene graph implementation that supports multiple rendering threads reading from a single scene graph, and drawing to multiple windows.
• Thread-safe scene graph implementation that supports multiple application threads simultaneously writing to a single scene graph.
• Support for tiled surface display. OpenRM is compatible with CAVELib, and other frameworks for creating multi-display graphics applications.
• Configurable multpass rendering: 3D Opaque/3D Transparent/2D.
• Full attribute inheritence along scene graph depth. No weird sibling inheritance as in some other scene graph implementations.
• Support for binocular analglyph and multibuffered stereo.
• Object/Objects picking.
• First class support for user-written immediate mode primitives.
• Built-in primitives that provide pretesselated surface models of cones/cylinders/spheres using triangles (not quads, as in GLU).
• Direct volume rendering support on Unix and Windows platforms (RM Scene Graph, the father of OpenRM, was probably the first scene graph API to provide first-class support for direct volume rendering).
• Full (read) access to render state in node callbacks.
• Model switching callbacks, combined with application-provided code can be used to implement LOD manipulation based upon model switching or other view dependent operations, such as frustum culling.
• Node traversal masks for detailed and fine rendering control.
• Multiple views and/or viewports within a window can be used to create multiple views of a 3D scene, or annotation displays such as a "Heads-up display" for out-the-window flyover views.
• OpenGL vertex arrays used wherever possible/feasible.
• Use of OpenGL display lists for built-in primitives wherever possible.
• Sprite and bitmap primitives in 2D or 3D.
• Imaging model supports index-color or true color image data in textures and sprites, as well as scale/bias.
• Hardware assisted imaging operations, including image resize
• One text model portable across X11 and Win32 .
• Built for use on both X11 and Win32 platforms.
• Direct control over the depth buffer, including background depth buffer images.
• Direct control over the color planes of the framebuffer, including background color image tiles.
• User defined clipping planes.
• Applications can use their own event loop handler, or use and modify the RMaux event loop code. OpenRM can be used to build a standalone application or can be combined with other applications or toolkits that provide event loop management (such as the CAVElibrary).
• Easy to use OpenRM with other event and widget/UI frameworks, like the Fast Light Toolkit (FLTK). Coding examples for combining OpenRM with FLTK are freely downloadable.
• Loads of documentation. The OpenRM documentation includes web-based "man pages" for the API, details about the demonstration programs, links to technical papers and resources, and a publication quality, 450+ page Programming Guide.

If that's not enough, consider that OpenRM is based upon commercial technology, RM Scene Graph from R3vis Corporation.

Despite all those neat features, there's a lot of work to do. Here's the current "hot list," arrange in approximately priority order.

1. GLUT+OpenRM demo programs and documentation. The Gordo distribution contains several FLTK+RM examples. We intend to expand the example base to include GLUT+RM examples, and to write the GLUT+RM Chapter for the Programming Guide.
2. Statistics & Performance measurement. Some rudimentary facilities within OpenRM exist for measuring performance. They are not documented either in the man pages or in the programming guide. Check out the vis3d.c demonstration program for example code. Look for routines of the form rmStats*. The reason these routines are not documented is because the API is still too immature to call it "production code." However, those routines do work and can be useful for those interested in measuring performance.
3. rmdemos - A number of improvements are scheduled:
   1. Add a command-line flag that enables/disables printing of per-frame statistics. Right now, some demos print such information whether you want them to or not. Other demos have such a switch already in place.
   2. For the demos vrend, vslicer, we need to detect the amount of texture memory available to applications and respond accordingly. At the present time (July 2003), the size of the default dataset exceeds the maximum texture size permitted by Mesa, which is a common development platform. August 2005 update: an early prototype of texture memory interface code is present in the tfly demo, which will query whether or not the large textures used for wall and sky boxes will actually fit, and then resize them if they are too large.
4. Offscreen rendering. On X platforms, we use a GLX pixmap for offscreen rendering. A few years ago, pbuffers were not as widely supported as they are now. We need to port the X11 offscreen rendering code to use pbuffers when they are available.
5. Volume rendering. The OpenRM octmesh generates geometry that is aligned with the axes of the underlying grid. The generation code needs to be updated to generate geometry that is perpendicular to the line of sight.
6. CVS Access. To partially satisfy the CVS appetite, we can set up a nightly or weekly tarball on the r3vis.com website. We will probably not be doing a CVS repository on sourceforge due to a history of CVS problems on that server.
7. File loaders/writers. We have added support for JPEG & PPM i/o, but there are many other popular image formats to support, as well as support for geometric model loaders, and support for OpenRM native binary save/restore. Basically, there is a lot of work to do on the subject of loaders.
   1. An RM-specific save/restore feature set to quickly save and load entire scene graph structures to disk files (a la PFA/PFB).
   2. Loader support for MultiGen .obj files.
   3. Loader support for VRML files.
8. Intersection/collision detection. The idea is to quickly determine whether or not some point or volume in space intersects anything in the scene, and if so, what and where.
9. Texture paging/texture management. There is none at this time. Either all the textures fit or they don't. This area obviously needs work.
   1. Detect whether or not a given texture will fit into texture memory. If not, report and error. This condition (tmem starvation) will occur when using either of the demo programs vrend.c or vslicer.c with any current Mesa implementation. Both of those programs will generate an OpenGL error code when running with Mesa, but will continue to execute. Visually, the results appear to be untextured geometry.
10. Other language bindings, such as C#, to better support Web-enabled use of RM in graphics and visualization applications. One OpenRM user contributed some bindings to C#. We are in the process of investigating that work now.