Hi Guys,
You probably know this but if not it may be other option for you. One can
define restart index that works as terminator for triangle/quad strips
(check GL_NV_primitive_restart extension) . So in practice multiple triangle
strips can be separated by restart indices and put into one physical
PrimitiveSet. Other option doing the same is adding 2 degenerated triangles
(2 extra indices or vertices) linking end of prior strip with start of next
strip. And you can use this trick on older boards in the same way as
primitive terminator.
Cheers,
Wojtek
-----Oryginalna wiadomość-----
From: Jean-Sébastien Guay
Sent: Friday, January 28, 2011 4:44 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP)to
DrawElements(TRIANGLES)
Hi Tim,
If I understand correctly how the sky dome mesh is constructed, there
was a lot of duplication of vertices in the triangle strip arrays, and
this has been carried forward into your indexed mesh approach. The
INDEX_MESH optimizer would remove these duplicates. The order of the
triangles in the output of INDEX_MESH should be the same as the input
order, but it might be tricky to pick corresponding triangles out of the
new mesh. Since this is such a regular mesh, the vertex cache optimizers
would make a small difference; however, you would totally lose the order
of the mesh.
Incidentally, I tried running the INDEX_MESH optimizer on the created
subgraph (at the end of the constructor in the file I attached in my
previous post) but it would crash in MyTriangleOperator::operator() - it
goes out of bounds on the _remapIndices list. The other two optimizers
also go out of bounds in similar ways.
Here's a modified Sphere.cpp with the code from the MeshOptimizers
simply copied into it (for simplicity of testing) if you want to have a
look.
I'm still not sure the order of the mesh is really important. I said
that before because it would have explained why the strips were arranged
like that, but I'm not sure now. So if I could get the INDEX_MESH
optimizer not to crash, I think using that and the other two (post/pre
transform) would probably work well. I could test it and see at least.
What was the actual performance difference?
With only the skydome in the scene, Draw went from about 0.45 to 0.4 on
my i7 920 + GTX 260. However it made the number of batches (draw calls)
go way down, of course - replacing 768 draw calls by 16 is good, but I
guess we could do better.
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
