What is OpenRM Scene Graph?
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.
OpenRM Features and Strengths? or, Why You Should Use OpenRM?
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
- 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
- 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
- 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
- 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.
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.
- 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.
rmdemos - A number of improvements are scheduled:
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- An RM-specific save/restore feature set to quickly save and load
entire scene graph structures to disk files (a la PFA/PFB).
- Loader support for MultiGen .obj files.
- Loader support for VRML files.
- 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
- Texture paging/texture management.
There is none at this time. Either all the textures fit or they don't.
This area obviously needs work.
- 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.
- 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.