When designing code to map graphical information to HOOPS Visualize primtives, first review the available primitive types and select the appropriate ones to represent your data:
These include NURBS surface, NURBS curve, circles/ellipses (and their variants), cylinder/polycylinder and spheres. Using these primtiives in lieu of explicit tesselated primitives whenever possible will result in performance improvements and memory reduction.
These include primitives such as shells, meshes, and polylines. The key guideline to follow is to use a shell primitive for each higher level 3D object in the scene, such as a solid modeller body. This minimizes duplicate vertices (which in turn eliminates 'cracking' in models if the HOOPS/Stream toolkit is used to compress the data), enables tristripping across boundaries and also allows HOOPS Visaulize to automatically generate more useful Level-of-Detail representations.
A shell consists of a vertex list and a face list, where the face list is a list of indices into the vertex list. For any face in the face list, the vertices can be listed either in clockwise or in counterclockwise order, as viewed from the front of the face (Figure 7.2.4.a).
The orientation in which you choose to enter the faces is not important; however, the faces in a single shell should all have the same orientation. One reason for this requirement is performance - HOOPS can create much longer tri-strips if all faces in a shell have the same orientation.
A second reason that all faces should have the same orientation is so that the object has a consistent handedness. This will enable you to set a polygon handedness, and also use backplane culling to throw away back-facing faces using the backplane cull heuristic (refer to the next section, along with the Set_Heuristics command for more information).
If the faces in a shell do not all have the same orientation, HOOPS Visualize will issue a warning. Note that some applications that produce tri-strips generate the tri-strips with alternate faces oriented in opposite directions - and that is the absolutely worst case with respect to maximizing tri-strip length.
The Compute_Optimized_Shell routines supports an option called "fix handedness", which converts all faces to the handedness that represents the pre-fix majority. There is also a program called fixshell.c in the demo/common/standard directory of the HOOPS Visualize distribution that shows how to reorient the faces of a shell.
Polygon handedness refers to the orientation of the faces in a shell defining which side is 'front' and which is 'back'. For example, wrap your right hand in the direction of the point ordering for a face in the shell (all faces should be ordered in the same way). The direction of your thumb denotes the 'front' side of the face (thus the 'front' denotes the 'outside' of a shell if it's a closed object). If your thumb is currently pointing in the correct direction for your object, then it has 'right handed' polygons. If it's pointing in the wrong direction (inward!), then your object has 'left handed' polygons.
It is set via the polygon handedness option in Set_Heuristics. If you are using the OpenGL driver, you should always set a polygon handedness on your models because it improves general rendering performance and is the prerequisite for the use of display lists which are an option in Set_Rendering_Options. Display lists can provide significant performance with most graphics cards. Their usage is discussed in detail in Section 7.4.1.
Polygon handedness is a property of the model. It's possible that shells may have different values (some may be 'left', some may be 'right'). If you know that all your shells have the same handedness, then you should place the polygon handedness setting at the top of your model hierarchy. To use polygon handedness to maximize effect in optimizing rendering performance, set the following properties:
Backplane culling is set via the backplane culling option in Set_Heuristics. It could also be considered a property of the model, and the following steps would be a good approach for setting this attribute:
A shell consists of a list of vertices and a list of faces. The face list consists of a list of indices into the vertex list. If two faces share a common edge (which is common in shells), then these two faces should share some of their vertices in the vertex list. For example, a shell representing a cube should be defined with a vertex list containing eight vertices and a face list containing six faces, with each vertex shared by three different faces.
Of course, sharing of vertices is not required. It is perfectly legal to define a cube by specifying the four vertices for each face separately. In such a definition for a cube, the vertex list would contain four vertices for each face, or 24 vertices instead of eight. In addition to wasting space, failing to share vertices makes it much harder for HOOPS Visualize to form long triangle strips, and thus can slow down rendering significantly.
Thus, you should share vertices whenever possible. Visualize also provides a command, Compute_Optimized_Shell, that removes redundant vertices from the vertex list.
Level Of Detail
The HOOPS/3dGS Level of Detail capabilities can be leveraged to create polygon decimated variants of shells, which in turn improve rendering performance since fewer triangles are drawn. Level of Detail representations are typically created for the purposes of allowing HOOPS/MVO 'constant framerate' logic to operate more effectively.
Skinning
Fields such as FEA and GIS frequently contain graphical representations of data that contain internal faces. For example, the FEA field involves the use of 'meshing' tools which may create 3D volumetric meshes. (similar to a Rubick's Cube) The HOOPS Visualize shell primitive can be used to represent this object. However, if the end-user is visualizing the object with face's visible and can only see the surface/skin of the object, then HOOPS/3dGS is spending excess time drawing the internal faces which can't be seen. It would be more optimal to have a variant of the object which just contains the faces on the surface, or 'skin' of the object.
The routine Compute_Optimized_Shell supports an option called 'skin' which will cause it to abandon its normal goal of merging nearby vertices in favor of extracting the exterior surface from shells that also have interior vertices and faces. This routine enables creation of the skin variant of the shell. You would modify your code to display the skin variant as long as the current rendering settings do not allow the user to see internal faces. If the user wanted to see a wireframe representation, you could then switch to the full 3D 'volume' variant (the variant containing internal faces).
For cases in which you want to render point cloud data which often consists of a large number of data points, we suggest that you present these data points as vertices in a shell. This shell without a face list then can be rendered with significantly high performance without sacrificing detail by calling to Set_Variable_Marker_Size, setting the marker drawing option in Driver Options and vertex decimation in Rendering Options with appropriate values. This is discussed in the detail in the section on vertex markers.
Next | Previous | Index |