5.6.1. The Ray-tracer Geometry Objects

The DirectViz ray-tracer maintains an internal structure that highly depends on how the SoSeparator SoSeparator SoSeparator nodes of a scene graph are organized. This internal structure is primarily composed of the geometrical parts of the scene graph, which are divided into entities – the OpenRTRT geometry objects .

The geometry objects are to the OpenRTRT ray-tracer what display lists are to OpenGL. They play a role similar to OpenGL display list for storing graphics data in optimized form for the rendering engine.

When a geometry object is defined, a corresponding acceleration data structureis built for very fast spatial search of ray intersections. This is a key optimization for ray-tracing. A top-level acceleration structure is also maintained by the ray-tracer to manage instances of geometry objects, with associated geometric transformations, for fast searching of ray intersections across all geometry objects of the scene.

This scheme can efficiently handle thousands of object instances as well as fairly large objects, possibly with dynamic transformations. However ray processing may slow down if there are too many objects, if objects are spatially overlapping, or if geometry objects are very large. In some cases, for optimal performance, geometry objects may then need to be split, grouped, or spatially balanced to work within these constraints.

The general performance in interactive applications may depend highly on creation and use of geometry objects. A cache mechanism – similar to Open Inventor render caching for OpenGL display lists – is used to automatically manage updates yet minimize the reconstruction of the ray-tracer's geometry objects. Since an acceleration structure must be recomputed, rebuilding a geometry object can take significantly more time than creating the corresponding OpenGL display list, in particular for large objects.

By default, DirectViz creates a single geometry object for each traversed shape. This is appropriate for recomputing acceleration structures only for changed shapes. Note that the geometry object also stores information relating to applied shaders (shader indexes), so the cache may be invalidated and the object rebuilt when shaders applied to the object are changed.

This mechanism can be tuned to possibly increase performance of rendering and/or scene editing by setting the directVizCachingfield of SoSeparator SoSeparator SoSeparator nodes to the appropriate value (see the section called “Performance guidelines”).

The directVizCachingfield tells DirectViz how to handle the shapes beneath an SoSeparator SoSeparator SoSeparator node in order to build the geometry objects, just as the field renderCaching controls OpenGL display list caching.

  • If the directVizCaching field of a given SoSeparator SoSeparator SoSeparator node is set to OFF (the default), DirectViz will build one geometry object for each shape beneath the separator.

  • If set to ON, DirectViz will build one internal object for all the shapes below, and the directVizCaching field is ignored for all of the SoSeparator SoSeparator SoSeparator nodes below.

Note that unlike the SoSeparator SoSeparator SoSeparator renderCaching field, in the current release of DirectViz there is no automatic mode (AUTO) where Open Inventor decides whether cache should be used based on some heuristic. The directVizCaching field must be set depending on the specific application.

Every time a geometry node is modified, the associated geometry object must be rebuilt. Thus, you should avoid putting dynamic parts of a scene graph under SoSeparator SoSeparator SoSeparator nodes with directVizCaching field set to ON. The animated part would cause the full content of the separator to be rebuilt and the performance could be very poor.

SoSeparator
  {
  SoCube {}
  SoCone {}
  SoSphere {}
  }

The DirectViz internal structure will here be composed of three geometry objects, one for each Open Inventor shape.

SoSeparator
  {
  directVizCaching ON
    SoCube {}
  SoCone {}
  SoSphere {}
  }

The DirectViz internal structure will here be composed of only one geometry object, because the directVizCaching field of the SoSeparator SoSeparator SoSeparator node is set to ON.

[Important]

DirectViz and dynamic scenes

  • DirectViz can handle animations based on geometric transformation updates very efficiently. Such “rigid-body” animations can be visualized in real time with ray-tracing. Also objects can be manipulated interactively, for instance with Open Inventor transform manipulators.

  • You can also animate shapes by editing their vertex coordinates, However you should take into consideration the time spent in rebuilding the acceleration structure. For example, 1 million polygons may require about 10 seconds to be processed. In cluster mode, one should also take into account the transmission of scene updates to the slaves. While possible, this type of animation should involve a limited number of polygons for real-time performance with the current release of DirectViz.