OpenGLContext.scenegraph.indexedfaceset

Indexed Face-set VRML97 node implemented using ArrayGeometry
XXX This node needs some serious optimization. Possible approaches:
display-list-generation, probably the most appropriate approach of them all, as it will almost certainly provide a serious speed boost. This can be a fairly simplistic mechanism, as it won't need the tesselator, and it can simply process the values as a stream of instructions. OpenGL 3.x deprecates display-lists... GL_TRIANGLE_STRIP, GL_QUAD_STRIP -- can dramatically reduce memory bandwidth, requires some serious analysis of the topology to get a decent result while keeping VRML semantics IndexedPolygons -- a single index array or equal index arrays can be rendered without expansion Double vs. floating point -- be able to downsample arrays to 'f' type if the data can be precisely stored within a 'f' type array GL_ATI_vertex_array_object -- cache arrays on the "server" side of the GL engine then use them from there GL_EXT_vertex_array_set -- cache the arrays in the client-side GL engine with all arrays together and the associated enables etc. should make the call to render a single restore of state and then glDrawArrays() -- note that I (mcf) don't have this extension available, so can't implement this.
GL_EXT_compiled_vertex_array
should be used if available, alternate version of same functionality GL_EXT_static_vertex_array. This is only useful if we are making multiple calls to render, which we are currently not doing.
cache index-sets: used to do a take of the data-arrays to get triangles-arrays depends on the index arrays and the tessellation-types
if no tessellation required: possible to update the entire coordinate array and just re-take before rendering all-equal-index sets: basically if the indices arrays are all identical we could use an index-based array-drawing call, which avoids the take-calls entirely, see IndexedPolygons for an implementation. if tessellation required: store polys-to-tessellate as meta-indices depends on the index-sets re-tessellate whenever coordinates change store end-of-data-array indices depends on everything, used to decide where the new values start writing if the data array has changed, then is the length of the data-array

Functions

Classes

Compiles to a display-list for static geometry
Note that this implementation is basically without real purpose, the arraygeometry version should be much faster on all modern hardware, particularly if VBO support is available.
Also note that display lists are deprecated in OpenGL 3.x
Indexed Face-set VRML97 node
The IndexedFaceSet is the most common VRML97 geometry-node type. Most 3D modellers will export most geometry as IndexedFaceSets, as they are the most general of the polygonal geometry types.
The OpenGLContext IndexedFaceSet node tries to follow the VRML97 IndexedFaceSet node's semantics as closely as possible whenever those semantics are defined. If you detect non-conformant operation, please report it as a bug in OpenGLContext.
There are a number of major sub-types of IFS: have coord + normal need to tesselate need to get simple triangle-points array need to get simple normals array # may need texCoordArray as well # may need color as well have coord but no normal need to tesselate need to get simple triangle-points array need to calculate normals for (face/vertex) # may need texCoordArray as well # may need color as well have only a single index-set, but 2 or 3 arrays could just use indexed drawing if all elements are triangles, in this case we don't have _any_ real overhead for a delta on the points/normals/colors, what would VRML do?
have everything once tesselated, we have a simple "take" to get values