Functions | |
HC_KEY | Insert_Shell_By_Tristrips (int pcount, const HC_POINT *points, int tristrips_length, const int *tristrips, int face_indices_length, const int *face_indices) |
HC_KEY Insert_Shell_By_Tristrips | ( | int | pcount, |
const HC_POINT * | points, | ||
int | tristrips_length, | ||
const int * | tristrips, | ||
int | face_indices_length, | ||
const int * | face_indices | ||
) |
Generates an object that is an arbitrarily-connected collection of arbitrary polygonal facets.
pcount | - Number of valid points in points. |
points | - Vector of x-y-z triplets for the coordinates of the vertices to be used to build the shell. (A simple N x 3 array may also be used.) Passed by reference always. |
tristrips_length | - The length of the tristrips array. |
tristrips | - An encoded description of the connectivity of points into triangle strips. |
face_indices_length | - The length of the face_indices array. |
face_indices | - An encoded description of how triangles should be combined to form faces, and the assignment of face identifiers. Can be null. |
Insert_Shell_By_Tristrips() differs from the regular Insert_Shell() routines in that the point connectivity list, 'face_indices', describes only triangles rather than any other types of polygons. The polyhedron that results from the connected triangles is a triangle strip, or tristrip
A tristrip is a series of adjacent triangles, organized such that after the first triangle, every additional triangle can be specified with only a single vertex. It is a primitive that is very efficiently supported by graphics acceleration hardware. HOOPS has its own internal tristrip generation logic, the output of which can be retrieved via Show_Shell_By_Tristrips() . HOOPS provides the _By_Tristips() insertion routines so that applications can leverage any special knowledge of their data into better (i.e. longer) tristrips than HOOPS might generate by default.
The tristrips argument is an array of integers that describes the triangle strips. It is a list of an unlimited number of independent triangle strips placed contiguously in memory, one after another. Each triangle strip begins with the number of vertices referenced, and then the list of vertices. Vertices 0-2 form one triangle. For every n such that 2 < n <= number of vertices, a new triangle is introduced. This new triangle will be [n-2, n-1, n] for even n, and [n-1, n-2, n] for odd n (to maintain consistent handedness of the triangles). Degenerate triangles (triangles which reference the same vertex more than once) are allowed. The length of this array should be given as a number of integers, the number of triangles plus 3 per independent triangle strip.
If the face_indices argument is NULL, each triangle will be its own face, and will be given a consecutive face ID in order of appearance. If face_indices is not null, it describes:
As HOOPS walks the tristrips array, for each new triangle that is created, it looks at the next entry in the faces_indices array. This implies that because of the overhead in the tristrips array at the beginning of each tristrip, faces_indices[i] will not correspond to the triangle introduced in tristrips[i]. The length of this array needs to be equal to the number of triangles. The burden is on the application to make sure that all face identifiers are used. If a face identifier is left unreferenced, the behavior is undefined.
SHELLS BY TRI-FAN
HOOPS allows users to specify tri-fans when using C_Insert_Shell_By_Tristrips. A negative vertex count will be interpreted as the start of a triangle fan. HOOPS will pass these through to OpenGL. Note, however, that the HOOPS internal tristripping algorithms do not generate their own triangle fans.
Suppose you have a shell that happens to be shaped like a 6-sided prism (an approximation of a cylinder for which Insert_Cylinder would probably be best, but still a useful example). The standard face list might look like
4 0 1 3 2 4 2 3 5 4 4 4 5 7 6 4 6 7 9 8 4 8 9 11 10 4 10 11 1 0 6 0 2 4 6 8 10 6 11 9 7 5 3 1
The regular Insert_By_Tristrips would look like
14 0 1 2 3 4 5 6 7 8 9 10 11 0 1 6 0 2 10 4 8 6 6 1 11 3 9 5 7
but could also be done with Insert_By_Tristrips using a triangle fan
14 0 1 2 3 4 5 6 7 8 9 10 11 0 1 -6 0 2 4 6 8 10 -6 11 9 7 5 3 1
Note that the list of vertices referenced by the triangle fan is identical to the caps of the original face list. One important difference, though, is that there is an implicit assumption in the case of the standard face list that all of the vertices referenced by the face are coplanar. There is no such assumption for triangle fans, so the 3d locations of its vertices are unrestricted. Another important difference is that edges between triangles will be visible unless they are specified as part of the same face by the face_indices array.
It is not necessary to close each face explicitly by going back to the start point. If you do close a face, the close point will be discarded as the shell is stored in the database.
It is not necessary for the polygons to be connected to each other. It is not necessary for all the input points to be referenced in face_list.
It is permissible for shells to be degenerate—the number of points in a shell can be zero. The number of faces in a shell can be zero. The number of vertices in a face can be as few as two, one, or even zero. Points can be redundant. More than two faces can share the same edge. Edges can be of zero length.
In the present implementation there are no "sharp" edges or vertices. In other words, smooth-shading, if turned on, always proceeds across shared edges and vertices, thus "rounding off" the edge or vertex. The only way to prevent this is by duplicating the edge or vertex so it is no longer actually shared between the faces.
The boundary of a face should not intersect itself.
If you work in 3-D, make sure the points in each face lie in the same plane. The system does not check for this—but displayed pictures might look strange.
If you work with a C compiler (and matching HOOPS library) with an "int" defined as only 16 bits, life can be difficult. Pcount and flist_length are defined as integers, so in this rare case would not be able to exceed 32767. One work-around is to use Edit_Shell_Faces() and Edit_Shell_Points() to "grow" an initially-small shell to a large size. But be warned that Open_Face() , Open_Edge() , Open_Vertex() , and Show_Selection_Element() also deal in integers and therefore won't work with an "overgrown" shell.
If the shell is closed (the viewing camera is not within the object), and if the transform-and-clip operation is done is software, HOOPS always performs a "backplane cull" (see Set_Heuristics() ) before drawing the shell.
If there is an error the Insert routine returns a -1.
HOOPS does not know how to handle self-intersecting polygons in shells and meshes. In addition, shells with holes are not handled correctly if a polygon edge and a hole are share the same vertex.