VRML (Virtual Reality Modeling Language) has become the de facto standard for 3D data on the Internet. Originally conceived as a format for describing multi-user immersive 3D worlds, VRML is finding many more uses as a format for sharing 3D data, for example engineering models, and for packaging 3D presentations that combine sound and animation. The availability of authoring tools and software development tools has lagged behind the availability of VRML viewers, forcing many content authors and software developers to resort to “doing it by hand.” That situation has changed with the release of the Open Inventor toolkit, which includes direct support for the VRML nodes.
Open Inventor is probably the most widely used C++ graphics toolkit in the world. Originally developed by 3D graphics experts at Silicon Graphics Inc., Open Inventor has been implemented by FEI on almost every major platform, including Windows. Open Inventor is a mature class library that has been debugged and tuned for many years. Anything from a single object to a complete scene can be represented as a tree structure called the “scene graph.” The scene graph contains “nodes” representing geometry, transformations, attributes, lights, and other data. Once a scene graph has been defined, Open Inventor takes care of rendering the geometry onto the screen. Unlike “immediate mode” graphics libraries, Open Inventor frees the application program from passing objects vertex-by-vertex for every redraw. The Open Inventor scene graph is complemented by powerful utilities including interactive viewers, geometry manipulators, and attribute editors. Open Inventor is used to implement applications, utilities, ActiveX controls, and browser plug-ins.
In many respects Open Inventor is VRML, or at least the parent of VRML. VRML 1.0 was sometimes half-seriously characterized as “Open Inventor without the good stuff.” The VRML 1.0 spec was taken directly from Open Inventor’s file format, with the addition of the WWWAnchor and WWWInline nodes. These two nodes were added to Open Inventor in release 2.1, making Open Inventor a true superset of VRML. Release 2.1 of Open Inventor also introduced the SoVertexProperty SoVertexProperty SoVertexProperty node, which allows coordinates, normals, and colors to be associated directly with geometry. This direct association replaces the traditional inheritance of coordinates and attributes through the scene graph and allows additional optimizations at rendering time. It also introduced two new field types, SoSFNode SoSFNode SoSFNode and SoMFNode SoMFNode SoMFNode , which allow a node to “contain” another node (for example an SoVertexProperty SoVertexProperty SoVertexProperty ) which is not a “child” in the usual hierarchical sense.
The VRML specification adopted this direct association model as the only way of associating coordinates and attributes. Except for transformations, there is no inheritance in a VRML scene graph. VRML also makes extensive use of SoSFNode SoSFNode SoSFNode and SoMFNode SoMFNode SoMFNode fields in order to allow multiple nodes to reference the same coordinates and/or attributes. In both cases, it is simply one step further in the direction indicated by the SoVertexProperty SoVertexProperty SoVertexProperty node. VRML continues to both borrow from and extend the Open Inventor model. Open Inventor is a superset of VRML.
Compared to VRML 1.0, the VRML97 specification also made the following changes/additions, most of which are taken from, or closely resemble, Open Inventor concepts:
Defined a set of engines as standard nodes, for implementing animation. The TimeSensorand various interpolators are similar to SoTimeCounter SoTimeCounter SoTimeCounter and existing interpolator nodes.
Defined a set of draggers as standard nodes, for interactively manipulating geometry. The SphereSensor , for example, handles mouse motion similar to the corresponding dragger, but is part of the scene graph and has fields that can be connected to other nodes.
Defined a set of sensors as standard nodes, for detecting user actions and viewer (camera) position. The TouchSensor , for example, handles mouse button and motion events in the scene graph similar to SoEventCallback SoEventCallback SoEventCallback , but has fields that can be connected to other nodes.
Defined a new syntax for specifying field-to-field connections in a file. Instead of having connected nodes appear inline with the connected field, separate ROUTE statements define the connections between fields. This is a significant improvement in readability.
Defined a generalized programmable engine called a “Script” node. The Script node has an arbitrary set of input and output fields and an algorithm specified in an appropriate language.
Defined multimedia nodes for embedding 3D spatial sounds in the scene and for applying a video clip as a texture map.
Defined what is effectively a macro capability in a scene graph file using the PROTO and EXTERNPROTO constructs.
With the ISO/IEC 19776 (X3D) specification, VRML has been extended to support many new features. Of these new features, Open Inventor now includes support for:
2D geometry nodes
Line property node
Trigger and sequencer nodes
2D interpolator nodes
Notice that all of the changes are related to specifying information in a scene graph file. This is because VRML only defines a file format, not a toolkit or an API. Open Inventor, on the other hand, defines a tool kit, an API, and a file format. Typically a VRML file defines some “content” (an animated sequence, world, object, etc.) designed to be viewed in a special “viewer” or “browser.” CosmoPlayer™ is an example of a VRML viewer. Many other companies, also provide VRML viewers. Generally they are available for free by downloading from a web site. Using Open Inventor it is possible (actually easy) to create a viewer (player, browser, etc.) that can display Open Inventor, VRML 1.0, VRML97, or X3D files. But this is only one of the many possible 3D application programs that could be written with Open Inventor, making use of its VRML capabilities!
This section addresses the question “I’m already using, or have decided to use, Open Inventor for my application – why should I care about VRML nodes?”. There are three main reasons:
As VRML becomes more pervasive, it is increasingly important for applications to be able to import VRML geometry. However, the full VRML specification is complex and cannot be parsed without knowledge about the content (fields and types) of each node. Open Inventor can handle these files and is being used by some customers solely as the front-end file reader for Open Inventor, VRML 1.0, VRML97, and X3D files. This is effective because Open Inventor has node classes that exactly match the node definitions in each of these specifications. So the result of parsing a VRML file (for example) is a scene graph in memory that can be easily traversed to extract the information that the application needs.
It is also increasingly important for applications to be able to export VRML geometry. Again Open Inventor handles this, allowing the application to construct a VRML scene graph using the convenient Open Inventor classes and rely on Open Inventor’s built-in persistence capability (SoWriteAction SoWriteAction SoWriteAction ) to generate the corresponding file. Applications can create VRML scene graphs directly using the VRML node classes. Applications can also translate their Open Inventor scene graphs into VRML97 by using SoToVRML2Action SoToVRML2Action SoToVRML2Action . Finally, applications can use the file translator utility ivtovrml to convert Open Inventor files into VRML files.
The VRML nodes also add some interesting new capabilities to Open Inventor as far as what kinds of things can be saved in a file. It was always possible to embed simple animation in an Open Inventor file, but it was not possible to embed sensitivity to user actions in a file. With the VRML nodes, it is now possible to create files containing objects that respond to user actions including mouse motion, button clicks, and viewer position. For example, a VRML file can be created where an animation is triggered by the user clicking on a certain object (see SoVRMLTouchSensor SoVRMLTouchSensor SoVRMLTouchSensor ) or simply by the camera moving into a specified region (see SoVRMLProximitySensor SoVRMLProximitySensor SoVRMLProximitySensor ).
VRML scene graphs offer advantages for interactive programs. Initially it may seem awkward not being able to inherit attributes, but in general it is much easier to interactively modify attributes in a VRML scene graph. Suppose the user has selected some geometry and wants to change the color. In an Open Inventor scene graph we now have to find the Material node that defines the color of this geometry. Or alternately we have to find an appropriate place to insert a new Material node, then traverse the scene graph (collecting state), in order to correctly initialize the new node. This requires quite a bit of code and will not be discussed here, but you can look at the SoSceneViewerclass if you haven’t already implemented it yourself. However, if the user selected some VRML geometry, then we have a path (class SoPath SoPath SoPath ) whose tail node is a VRML Shape node (class SoVRMLShape SoVRMLShape SoVRMLShape ). We know that the Shape node contains a geometry node and an (optional) Appearance node (class SoVRMLAppearance SoVRMLAppearance SoVRMLAppearance ). We are guaranteed by the VRML specification that the geometry’s color is defined by either a VRML Color node (class SoVRMLColor SoVRMLColor SoVRMLColor ) contained in the geometry node, or a VRML Material node (class SoVRMLMaterial SoVRMLMaterial SoVRMLMaterial ) contained in the Appearance node. Look under “Color Editor” and “Material Editor” in the implementation the section called “ Material Editor” for a more detailed discussion of the algorithm for attaching these components.
Similarly it is much easier to find the transformation that most directly affects an object, because in a VRML scene graph that transformation is always defined by a direct ancestor. For example, the Shape node’s parent will usually be a VRML Transform node (class SoVRMLTransform SoVRMLTransform SoVRMLTransform ), which contains the local transformation for that Shape. In a traditional Open Inventor scene graph the local transformation could be defined by one of the other children nodes at the same level as the Shape, or any one of the children nodes in one of the levels above the Shape node. In a VRML scene graph, the transformation (if any) is always defined by the Shape’s parent or the parent’s parent and so on. Look under Manipulators in the implementation the section called “ Manipulators” for a more detailed discussion of the algorithm for inserting a manipulator.
Finally, VRML scene graphs can potentially be optimized more aggressively than traditional Open Inventor scene graphs. Because geometry and attributes are packaged together in the Shape node, it will be possible to extend the optimizations begun with SoVertexProperty SoVertexProperty SoVertexProperty to include additional types of optimization such as sorting the geometry to minimize expensive state changes in the rendering engine. This type of optimization is quite difficult in a traditional Open Inventor scene graph because attributes can be inherited both from parent nodes and from sibling nodes (other children at the same level in the scene graph). FEI is actively pursuing a number of optimization strategies to increase the performance of Open Inventor applications. Taking advantage of the VRML scene graph is a promising approach.
Open Inventor is somewhat unique in directly supporting the VRML nodes exactly as they are specified in the VRML specification. Most 3D graphics toolkits must do a conversion when reading or writing VRML files. This can result in information being lost when reading files. It can also result in inefficient or unexpected VRML data being generated when writing files. For example, some toolkits (and applications) allow the user to create a sphere, but when they save as VRML they actually output an IndexedFaceSet which significantly increases the file size. That doesn’t happen with Open Inventor-based applications, because Open Inventor’s VRML nodes correspond exactly to the nodes defined in the standard. For example, to create a VRML sphere in Open Inventor, you create an instance of the SoVRMLSphere SoVRMLSphere SoVRMLSphere class which has one field radius of type SoSFFloat SoSFFloat SoSFFloat . So, you can be sure that Open Inventor will write that object into a VRML output file exactly as expected.
Open Inventor is also somewhat unique in directly supporting VRML concepts like a “ROUTE” between two nodes. Most 3D graphics toolkits do not support this concept, meaning that information about animation is lost when reading a VRML file and that new animation defined by the user cannot be exercised within the application. Open Inventor has always had the concept of “field-to-field connections” and ROUTEs are just a different way of specifying these connections. That means you are working with reliable, tested technology and also that your Open Inventor scene graph corresponds directly to the VRML scene graph.
Some 3D graphics toolkits cannot render VRML geometry and attributes correctly because of limitations in their underlying rendering engine. For example some toolkits do not implement the complete lighting equation defined in the VRML specification and some toolkits only support “1-bit” transparency (transparency at each pixel is either on or off, no partial transparency). Open Inventor uses OpenGL exclusively for rendering. This allows Open Inventor to render VRML scenes accurately and also to take advantage of graphics accelerators for enhanced performance.
Many people developing VRML content are essentially “doing it by hand,” using a text editor for static files or CGI scripts for dynamically created files, but either way having to deal with VRML files as “text.” This is really doing it the hard way. Open Inventor can be used to extend your existing application(s) to directly export VRML files or to quickly create tools for generating VRML files. For example, Open Inventor makes it easy to create “server-side” applications that dynamically create VRML data. Open Inventor creates VRML scene graphs quickly and easily and ensures that they are written out with correct syntax. Open Inventor also makes it easy to create client-side applications that provide custom rendering, including Netscape plug-ins and ActiveX controls that can be embedded in your browser.
Some toolkits are beginning to appear that focus exclusively on VRML. Using one of these toolkits is an improvement over development “by hand,” but also very limiting. There are things that VRML simply can’t do that are extremely useful in an application. For example, Open Inventor supports true 3D text with extrusion and beveling, a triangle strip primitive (which usually can be rendered much faster than a face set), NURBS curves and surfaces and other features. Applications can save advanced Open Inventor nodes and VRML nodes in the same file when saving a project between sessions, then “publish” as pure VRML when the project is completed. Open Inventor’s SoCallbackAction SoCallbackAction SoCallbackAction allows the more advanced geometry like extruded text to be easily converted to triangles that can be specified as a VRML IndexedFaceSet.