Maximizing Rendering Performance

Scene-Graph Organization

An HSF file is essentially an archive of a HOOPS/3dGS scene-graph. Even if HOOPS/3dGS is not used as the graphics system for rendering, the organization of the scene-graph inside the HSF file can affect rendering performance. Optimal scene-graph structure is covered in the performance section of the HOOPS/3dGS Programming Guide. Critical areas include keeping segments to a minimum, organizing the scene-graph based on attributes rather than geometry, using ‘shell’ primitives whenever possible to represent tessellated data, and making sure that the shells are as large as possible.

Keep in mind that a scene-graph is meant to serve as an optimal organization of the graphical information, rather than higher-level application information such as ‘assemblies’, ‘parts’, etc… Structuring the scene-graph based on the organization of higher-level application data-structures, while perhaps convenient, can severely compromise rendering performance and memory usage inside the application which is doing the reading. However, the HOOPS/Stream Toolkit’s range of HSF opcode objects and customization facilities makes it easy to associate custom (non scene-graph) data with the scene-graph objects and store them in the HSF file, or store the external to the HSF file (perhaps as XML data).

Polygon Handedness

Polygon handedness is a basic vector graphics concept. The specifics are covered in the polygon handedness section of the HOOPS/3dGS Programming Guide, but in general, the existence of a polygon handedness setting for an object enables an application to render that object using backplane culling. This typically results in a significant increase in rendering performance.

If any HOOPS/3dGS ‘shell’ primitives can (or should) have a handedness defined for its faces, it is critical to make sure that the handedness attribute is set in the HOOPS/3dGS scene graph.

This is important because:

  • The reading application may not be able to determine what a proper handedness is for the shells

  • Even if the reading application can determine a proper handedness setting, the scene may look incorrect if the setting is made in the application and wasn’t made at the time of file export (and hence stored with the shells). This is because the HOOPS/Stream Toolkit will explicitly export compressed normals during the writing phase, and it is possible that these normals won’t be consistent with the handedness setting made in the reading application.

If the handedness attribute is going to be exported for a shell or group of shells, it is important to make sure that all the faces in the shell are all defined with a consistent point ordering. Otherwise some faces will be ‘backwards’, and the object will have holes in it if a viewing application renders the object by relying on the existence of a handedness setting to perform backplane culling.