<!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.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>Paul,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>We are using osgUtil::DelaunayTriangulator in a real-time package from 
which we'd like to export FLT.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>I was able to use the workaround we discussed for geometry created by 
osgUtil::DelaunayConstraint.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>However, the DelaunayTriangulator itself uses BIND_PER_PRIMITIVE as a 
means to bind normals to its output geometry. I could take the output normal 
array and generate a new one by iterating through all the vertices, but remember 
I said "real-time". If I change a simple road constraint, then no one will 
notice me generating a normal array. But it I regenerate the normal array for an 
entire terrain on every update in a real-time application, the user is 
definitely going to notice the difference. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>I understand the reasons why you don't like BIND_PER_PRIMITIVE -- a 
vertex can be a part of any number of primitives (consider TRIANGLE_FAN). So how 
do you determine the normal of a single vertex? Well, the way I did it is 
this:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT size=2><FONT 
color=#008000><BR>// types used for computing normal vectors<BR></FONT><FONT 
color=#0000ff>struct</FONT> SVertexData<BR>{<BR><FONT color=#0000ff><SPAN 
class=550565814-16092008>    </SPAN>unsigned</FONT> <FONT 
color=#0000ff>int</FONT> m_unNumPrimitives;<BR><SPAN 
class=550565814-16092008>    </SPAN>osg::Vec3f 
m_vNormal;<BR></FONT><FONT size=2>};<BR></FONT><FONT color=#0000ff 
size=2>typedef</FONT><FONT size=2> std::map< osg::Vec3f, SVertexData > 
TMVertexToDataMap;</DIV></FONT></SPAN><FONT face=Arial color=#0000ff 
size=2></FONT>
<DIV dir=ltr align=left><BR><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>Using this type of data structure, if we can find the vertex in that 
map, we multiply the two struct members together, add the normal of the 
current triangle, and divide by the struct member for the number of primitives 
plus one. Then we increment the number of primitives struct 
member.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>If it's not in the map, we insert a mapping from the vertex to a struct 
with this triangle's normal and a 1 for the number of 
primitives.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>After we've seen every triangle, then the map is fully populated and we 
can build the normal Vec3Array.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>I don't know what the FLT writer does, but osgUtil::DelaunayTriangulator 
is giving us back full triangles -- not a strip or fan. Depending on the 
GL_MODE, you might have to iterate differently to get to the 
triangles.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2>John</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=550565814-16092008><FONT color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> osg-users-bounces@lists.openscenegraph.org 
[mailto:osg-users-bounces@lists.openscenegraph.org] <B>On Behalf Of 
</B>Argentieri, John-P63223<BR><B>Sent:</B> Monday, September 15, 2008 10:27 
AM<BR><B>To:</B> osg-users@openscenegraph.org<BR><B>Subject:</B> Re: [osg-users] 
Paul, Another FLT Export BUG.<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>Paul,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>No, I was not aware of this. However, I am 
using BIND_PER_PRIMITIVE with 
osgUtil::DelaunayTriangulator/DelaunayConstraint as in the osgdelaunay example. 
Since I can quickly get the triangles, I just have to cross-multiply and 
normalize to get each primitive normal.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>The other thing that I could to is calculate the normals in 
the same way as above, but assign one to each vertex in a map. Then if a vertex 
is a part of two triangles, I could add the new triangle's normal and divide by 
two.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>In fact, I'll probably use the strategy above. Thank you 
for your help and your time, Paul.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>Have a great week! Your pal,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008><FONT face=Arial 
color=#0000ff size=2>John</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=185241914-15092008></SPAN> </DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr align=left><FONT face=Tahoma size=2><B>From:</B> 
osg-users-bounces@lists.openscenegraph.org 
[mailto:osg-users-bounces@lists.openscenegraph.org] <B>On Behalf Of </B>Paul 
Martz<BR><B>Sent:</B> Sunday, September 14, 2008 4:36 PM<BR><B>To:</B> 
'OpenSceneGraph Users'<BR><B>Subject:</B> Re: [osg-users] Paul, Another FLT 
Export BUG.<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=609043020-14092008><FONT face=Arial 
size=2>By the way, are you aware that BIND_PER_PRIMITIVE is the least efficient 
way to render in OSG? There is no OpenGL vertex arrays equivalent for this, so 
the best OSG can do to support it is specify slow path glBegin/glEnd calls 
stored in a display list. If you can fix your data to not use 
BIND_PER_PRIMITIVE, not only would you avoid this issue in the FLT exporter, but 
you'd also potentially experience a performance boost (depending on 
where your bottleneck is).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609043020-14092008><FONT face=Arial 
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=609043020-14092008><FONT face=Arial 
size=2>In fact, the reason this bug is in the exporter is probably because I 
didn't test BIND_PER_PRIMITIVE, thinking that no one really uses that binding 
anyway. (At least, no one who cares about performance uses 
it.)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609043020-14092008><FONT face=Arial 
size=2>   -Paul</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609043020-14092008><FONT face=Arial 
size=2></FONT></SPAN> </DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> 
  osg-users-bounces@lists.openscenegraph.org 
  [mailto:osg-users-bounces@lists.openscenegraph.org] <B>On Behalf Of 
  </B>Argentieri, John-P63223<BR><B>Sent:</B> Friday, September 12, 2008 2:49 
  PM<BR><B>To:</B> osg-users@openscenegraph.org<BR><B>Subject:</B> [osg-users] 
  Paul, Another FLT Export BUG.<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=Arial size=2>Paul,</FONT> </P>
  <P><FONT face=Arial size=2>We've found another FLT export BUG which happens 
  when geometry normal bind mode is BIND_PER_PRIMITIVE. It looks like it's 
  trying to convert the normal array to BIND_PER_VERTEX, but it fails. Here's 
  our example:</FONT></P>
  <P><FONT face=Arial size=2><<test.osg>> </FONT><BR><FONT 
  face=Arial size=2>In osgviewer, look at the surface and toggle both lighting 
  modes. Then convert and do the same.</FONT> </P>
  <P><FONT face=Arial size=2>I hope that helps! Your pal,</FONT> </P>
  <P><FONT face=Arial size=2>John Argentieri</FONT> <BR><FONT face=Arial 
  size=2>General Dynamics C4 Systems</FONT> <BR><FONT face=Arial size=2>Battle 
  Management Systems Division</FONT> <BR><FONT face=Arial size=2>Software 
  Engineer</FONT> </P></BLOCKQUOTE></BODY></HTML>