Hi John -- This is definitely a bug that needs to be fixed. and I'm sorry it is impacting your work.
What I'm getting at is that it would really be nice if the FLT writer could export the output of osgUtil::DelaunayTriangulator without having to put a normal vector generator on top of it. FLT only supports normal per vertex, so there will need to be some type of normal generation (at least duplication) in order for the exporter to support BIND_PER_PRIMITIVE. To me, BIND_PER_PRIMITIVE implies that the same normal is used at each vertex of the component primitive (quad/triangle/line segment/whatever). So, for example, given an array of 4 vertices to render 2 triangles, there would be 2 normals, one for each triangle. The correct output in FLT would be 6 entries in the vertex palette, 3 with one normal and 3 with the other, and the 2 shared vertices would have xyz values duplicated. (This is for Face record usage; Mesh might be different.) Currently, the structure of the FLT exporter is as simple as possible; when it encounters a Geometry, it blindly adds the data to the vertex palette without even looking at the primitive modes, and it currently depends on the binding being PER_VERTEX (as you have discovered). This is clearly wrong and needs to be fixed. To handle things correctly, either the data needs to be preprocessed up front to fit this usage before being added to the VertexPaletteManager, or the VertexPaletteManager itself needs to be smart enough to handle it. In either case the process would be as follows: We essentially need to change the Geometry data so that color and normal bindings are per vertex (this is a FLT requirement). This would involve iterating over all PrimitiveSets and doing a switch/case on the primitive mode, then copying existing data into new arrays. Also, we need to special case BIND_OVERALL color, because FLT files have the concept of a single color specified in the Face record. So we don't want to expand that out to BIND_PER_VERTEX. Then we also need to be sure to handle the "sharing" feature correctly. The current code is optimized to support two Geometry objects sharing the same vertex arrays; if the address of the arrays match, the code assumes the data is already in the vertex palette and simply indexes into the existing data. However, if we have to preprocess the data and generate new arrays on the fly to support BIND_PER_PRIMITIVE, then we must instruct the VertexPaletteManager to disable sharing for those arrays. I believe there is already a flag for this, as I had to do something similar for light points. All this is doable but tedious. I won't get to it in the next few weeks; I might not get to it until early next year (yes, I'm booked pretty solid these days). -Paul
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
