[osg-users] Paul, Another FLT Export BUG.

Argentieri, John-P63223 John.Argentieri at gdc4s.com
Tue Sep 16 08:22:50 PDT 2008


Paul,
 
We are using osgUtil::DelaunayTriangulator in a real-time package from
which we'd like to export FLT.
 
I was able to use the workaround we discussed for geometry created by
osgUtil::DelaunayConstraint.
 
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. 
 
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.
 
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:

// types used for computing normal vectors
struct SVertexData
{
    unsigned int m_unNumPrimitives;
    osg::Vec3f m_vNormal;
};
typedef std::map< osg::Vec3f, SVertexData > TMVertexToDataMap;

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.
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.
After we've seen every triangle, then the map is fully populated and we
can build the normal Vec3Array.
 
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.
 
John
 
________________________________

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of
Argentieri, John-P63223
Sent: Monday, September 15, 2008 10:27 AM
To: osg-users at openscenegraph.org
Subject: Re: [osg-users] Paul, Another FLT Export BUG.


Paul,
 
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.
 
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.
 
In fact, I'll probably use the strategy above. Thank you for your help
and your time, Paul.
 
Have a great week! Your pal,
John
 
________________________________

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Paul
Martz
Sent: Sunday, September 14, 2008 4:36 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Paul, Another FLT Export BUG.


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).
 
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.)
   -Paul
 


________________________________

	From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of
Argentieri, John-P63223
	Sent: Friday, September 12, 2008 2:49 PM
	To: osg-users at openscenegraph.org
	Subject: [osg-users] Paul, Another FLT Export BUG.
	
	

	Paul, 

	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:

	<<test.osg>> 
	In osgviewer, look at the surface and toggle both lighting
modes. Then convert and do the same. 

	I hope that helps! Your pal, 

	John Argentieri 
	General Dynamics C4 Systems 
	Battle Management Systems Division 
	Software Engineer 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/de4ae956/attachment-0003.htm>


More information about the osg-users mailing list