<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Paul, Another FLT Export BUG.</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16705" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=550565814-16092008></SPAN><SPAN 
class=550565814-16092008><FONT color=#0000ff size=2>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT size=2><SPAN 
class=657210816-16092008><FONT face=Arial color=#000000><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>Hi John -- This is definitely a bug that 
needs to be fixed. and I'm sorry it is impacting your 
work.</SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT 
  color=#0000ff><FONT size=2>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.<SPAN 
  class=657210816-16092008><FONT face=Arial 
  color=#000000> </FONT></SPAN></FONT></FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT size=2><SPAN 
class=657210816-16092008><FONT face=Arial color=#000000>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.</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT size=2><SPAN 
class=657210816-16092008><FONT face=Arial color=#000000>To me, 
BIND_PER_PRIMITIVE implies that the same normal is used at each vertex of 
the component primitive (quad/triangle/line 
segment/whatever).</FONT> <FONT face=Arial color=#000000>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.)</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>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:</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>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.</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>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.</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN 
class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>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.</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>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).</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN class=657210816-16092008>   
-Paul</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><SPAN 
class=550565814-16092008><FONT color=#0000ff><FONT face=Arial color=#000000 
size=2><SPAN 
class=657210816-16092008></SPAN></FONT></FONT></SPAN> </DIV></BODY></HTML>