[osg-users] Paul, Another FLT Export BUG.
pmartz at skew-matrix.com
Tue Sep 16 09:41:36 PDT 2008
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osg-users