Regardless of whether you are
using the HoopsStream classes to export an existing HOOPS/3dGS
scene-graph to an HSF file, or are using BaseStream to manually
export scene-graph objects to the file, it is important
you correctly organize your scene-graph. These items are
covered in more detail in the HOOPS/3dGS Programming Guide.
1. Minimize the number
of segments
Segments are intended to serve
as containers for groups of geometry and attributes. Object
with similar attributes should be grouped into the same
segment whenever possible. For example, if each object
needs to have it’s own modeling matrix, then you
will need to a separate segment for each. However, if
you have 5,000 lines that have similar attributes, they
should be grouped in the same segment
2. Organize geometry
based on graphical objects rather than application objects
A scene-graph is meant to serve
as an optimal organization of 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. For example, in an MCAD application,
you should use a segment to store the geometry/attributes
for each ‘body’ (since each body could have
a different modeling matrix, etc..), and use a single
shell primitive to represent the entire ‘body’
rather (rather than use a shell for each ‘face’
in the body)
3. Use large, optimized
shells
As mentioned in #2, you should
look for ways to make you shells primitives as large as
possible. HOOPS/3dGS also provides a routine for optimizing
shells (HC_Compute_Optimized_Shell) which can be used
in conjunction with HoopsStream classes. When using the
BaseStream classes, you can leverage a similar shell optimization
function located in the HOOPS/Tools library. These routines
remove redundant vertices and degenerate faces. Doing
so reduces memory usage, and increases tristrip length
(which in turn reduces the size of the HSF file, and also
improves rendering performance in the reading application).
4. Order shell faces
consistently, and set a polygon handedness
To construct the face of a
shell (or any polygon), a series of points are connected
in either a right-handed or left-handed sense. By definition,
if you wrap the fingers of the right hand along the vertices
of a polygon, with the wrist at the first vertex and your
fingertips at the last, then extend your thumb, your thumb
is extending out of the front face of the polygon and
the polygon sense is "right-handed". Likewise,
the same polygon with a left-handed sense will have the
same ordering of points but the front face of the polygon
will be on the opposite side.
Polygon handedness and front-face
direction becomes critical when trying to shade surfaces,
and in applying some rendering optimizations such as “display
lists” and "backplane culling", which
can only be used of a “polygon handedness”
has been specified. If handedness is not consistent, shading
algorithms produce bad results and this forces HOOPS to
compensate. The extra work of searching for and flipping
the orientation of inconsistent faces can slow rendering
by up to thirty percent.
The optimal setting for any
model is to set “polygon handedness” Heuristic
to either "right" or "left" for all
shell primitives, and to set the "backplane culling"
Heuristic set to "on" for any closed shell primitives.
These are set by calling HC_Set_Heuristics when using
HOOPS/3GS and the HoopsStream classes, and by using the
TK_Heuristic opcode when working with the BaseStream classes.
5. Use include references
The HOOPS/3dGS function HC_Include_Segment
allows nodes to link with the geometry and attributes
of other nodes without making extra copies of data. The
technique of using included segments wherever possible
saves large amounts of memory and should be used wherever
possible. When using the BaseStream classes, you can specify
an inclusion by using the TK_Referenced_Segment opcode.
The HoopsStream and BaseStream
classes provide support for a variety of export options.
Many of these options control compression settings which
reduce the size of the HSF File. Refer to the HOOPS/Stream
Programming Guide for specific details on their usage.
1. Enable global compression
HOOPS/Stream utilizes a global,
lossless LZW compression technique. It is automatically
enabled when using the HoopsStream classes, but needs
to be manually specified when using BaseStream.
2. Enable vertex compression
A value of 36 bits of precision
(12 for each channel) has generally proven to provide
adequate visual fidelity.
3. Enable normal compression
We recommend using 24 bits
of precision (8 for each channel).
This should similarly provide adequate visual fidelity.
4. Enable connectivity
compression
This compresses 'shell' connectivity
information. This compression technique can provide compelling
reductions in files sizes for datasets that contain many
'shell' primitives.
5. Use global quantization
This causes any required quantization
to be global (using the bounding box of the scene) instead
of local (bounding box of each geometric primitive) .
The bounding box is set automatically when using the HoopsStream
classes, but it must be exported manually when using BaseStream
(by exporting a TKE_Bounding_Info opcode).
