Hi Robert,
If you use billboard quads then the OSG will have to depth sort all
the osg::Geometry of the quads, as well as do the cull and draw
traversals through all the separate nodes and geometry. Sorting just
a index array will only have the cost of the sort, and given the
nature of the data being sorted is actually likely much quicker than a
sort of geometry so will be far more efficient.
Just to make sure I understand, you don't mean sorting the indices
themselves, right? That would always give 0...n of course... So I'd have
to calculate the distance between the eye and the vertex at index i, and
then place the indices so that those distances go from largest to
smallest. Which is still not too hard, but a bit slower than sorting
unsigned ints of course... :-)
Another problem with this approach, how would that handle multiple
viewpoints? The vertices would be properly sorted from one viewpoint, but
not from the other(s)... Possibly only a custom Geometry would work for
that, right?
You'd have to one DrawElements object per view or context, or put a
mutex on it to serialize access to it. Personally I'd go for one
DrawElements per context.
OK, and then I'd have a custom osg::Geometry that would use the right
DrawElements for the current context/view in its drawImplementation?
Heh, yeah. One point sprite per Geometry :-)
Well one sprite per geometry will be just bit faster than using
billboards but not by much. The sprites gives you the ability to
clump points together to reduce the cost of the cull, draw dispatch
and GPU costs associated with drawing the particles. So it's be a
balance between accuracy of the sorting and performance, one sprite
per osg::Geometry being the best for quality, but awful for
performance.
I was joking obviously. :-) I think the idea above is not too hard to
implement and will give much better results (in performance) than one
sprite per geometry, while still being correct visually. If I make it
really nice and well encapsulated I could even submit it as an
osg::Geometry specialized for point sprites / particles. Speaking of
which, what does osgParticle do for its rendering of particles? I've
never looked at it, perhaps what I'm doing now is already
(partially/completely) done there?
On a different tack, I wonder if you could use OpenCL to do a sort of
the indices before they are used in OpenGL. I don't know how
possible/practical this issue.
I'm not at a point where I can dive into OpenCL right now... But it
could be interesting sometime in the future.
Thanks a lot for your thoughts on this subject.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
