CAE animations commonly involve models which are very large and/or dynamic from frame to frame. For example, each frame of a crash simulation could contain a unique facet set representing a time-based deformation of the car’s spaceframe. Storing every frame’s facet set inside the HOOPS scene graph might require too much memory, thus alternate approaches are necessary. Similarly, if the graphical information is changing between each frame, there is little benefit in retaining the dynamic data in the HOOPS/3dGS scene-graph.

A. Animation of Static Data

This refers to the case where the graphical representation of objects does not change from frame to frame, but rather only object positions change. Consider the animation of a car door opening/closing; the facet-set representing the car door does not change from frame to frame.

The most efficient way to animate such datasets is to simply use HOOPS/3dGS’ Set_Modelling_Matrix routines. Because the data is effectively ‘static’ you should also turn on ‘display lists’ using Set_Rendering_Options(“display lists”) to achieve maximum performance. In addition to directly defining these types of animations in HOOPS/3dGS, they can also be defined using the higher level animation capabilities included with the HOOPS/MVO Class Library. Refer to the HOOPS/MVO Programming Guide for more information.

B. Animation of Dynamic Data

Toggling Segment Visibility

For relatively small amounts of graphical data and a small number of animation frames, all the graphical information can reside inside the HOOPS/3dGS scene graph without memory usage concerns. The graphical info for each frame would be inserted under a HOOPS/3dGS segment. When animating, you would then loop through the segments, turning ‘off’ the visibility of the segment (segment tree) associated with the current animation frame, and turning ‘on’ the visibility of the segments associated with the next frame. After the first run-through, HOOPS/3dGS will have precalculated each shell’s tristrips, and at this stage the shells are effectively ‘static’ geometry. You should turn on ‘display lists’ using Set_Rendering_Options(“display lists”) to obtain maximum rendering performance. Pseudo segment tree and code:

/* turn off the visibility of all ‘frame segments’ */
for (i = 0; i < num_frames; i++)
{
  H C_Open_Segment_By_Key(<frame_segment_i>);
    HC_Set_Visibility(“off”);
  HC_Close_Segment();
}

  /* loop through the frame segments, toggling visibility and   updating the display for each */
  for (i = 0; i < num_frames; i++)
  {
    HC_Open_Segment_By_Key(<frame_segment_i>);
      HC_Set_Visibility(“on”);
      HC_Update_Display(); /* if using HOOPS/MVO, call                                             HBaseView::Update() */
      HC_Set_Visibility(“off”);
    HC_Close_Segment();
  }

Editing Existing Shells

For larger amounts of data and/or large numbers of frames, using an explicit set of HOOPS/3dGS graphical primitives for each frame is impractical, as the memory requirements would probably be too great. In this case, you should insert a single set of HOOPS/3dGS shells for the initial frame and edit them over time. (The presumption is that the graphical representation for each frame has been precomputed and either resides on disk or has already been read into your application data structures.) Specifically, prior to rendering each frame of animation, you would obtain that frame’s facet set representation and modify the existing HOOPS shells using the Edit_Shell_<data> routines.

There are some important caveats with this usage scenario:

• Since the shell points data is changing from update to update, ‘display lists’ should be turned OFF, otherwise the animation may run quite slow (display lists only help when the data is static from update to update, and incur a retransmission performance hit when they are modified)

• If both the # of points in a shell and the topology of each shell face are not going to change from frame to frame, then you should set Define_System_Options(“no restrip on edit”) to improve animation performance. Recall that by default, HOOPS/3dGS internally creates ‘tristrips’ when rendering a shell for the first time and caches those tristrips. If an edit occurs, HOOPS/3dGS assumes that it needs to re-tristrip, which is time consuming. If topology is not changing, then there is no need for HOOPS/3dGS to recalculate tristrips. (By ‘topology of each face’ changing, consider a 4-point face going from concave to convex.)

Pseudo segment tree and code:

  /* loop through based on number of frames, editing the shells (and   any other graphical primitives) with each frame’s new graphical   information */
  for (i = 0; i < num_frames; i++)
  {
    for (n = 0; n < shell_count; n++)
      HC_Edit_Shell_Points(<shell_key[n]>, <offset>, <delete>,                                 <insert>, <points for frame i>);

    HC_Update_Display(); /* if using HOOPS/MVO, call                                           HBaseView::Update() */
  }

In both cases above, animation performance can also be improved by inserting the shells by tristrip (Insert_Shell_By_Tristrips). If tristrip variants of the shells are handed to HOOPS, it will not perform a tri-stripping step during the first drawing of each shell. Note that the ‘no restrip on edit’ System_Option mentioned above would also become irrelevant in this case.

HOOPS/3dGS v16 will contain an enhancement to speed up the tristripping process. However, a related optimization may also be added, whereby the developer can tell HOOPS/3dGS to simply draw the shells as ‘triangles’ and not attempt to generate (or regenerate) tristrips, reducing initial or post-edit display time in exchange for a slight rendering performance hit.

This could be useful in 2 situations:

• When tristrip information is not available in advance (and thus the shell cannot be inserted using Insert_Shell_By_Tristrips), HOOPS/3dGS will currently always create tristrips. Again, this could be time consuming during the first rendering of a shell that has a new set of points, particularly if the shell is quite large.

• If the topology of a shell changes from one frame to the next, currently the only way for HOOPS/3dGS to product the correct picture is to re-tristrip. Once again, if HOOPS/3dGS were instructed to simply use triangles, it could forego the tristripping work. (The faces of each shell would still need to be re-triangulated in both the above cases, but the largest bottleneck from one frame to the next is re-tristripping)

Developers are encouraged to review Section 7.0 of the HOOPS/3dGS Programming Guide for additional performance guidelines.