Hi Robert,
2) Do fine grained depth sorting via a cull/draw callback. I'd sort contents of
a DrawElements rather than the vertices themselves, as this would allow
you to manage the vertices consistently in an animation/update
code you have.
I thought manually sorting all vertices might be too long since I can
have hundreds or thousands of sprites... But maybe not, I'd have to try
it. Also the other method I have of rendering the sprites is with
billboarded quads, which OSG can sort correctly itself, but which is
heavier in its graph layout. So I'll have to compare the two to see if
the sorting won't cancel out the gain that point sprites can give.
By sorting the contents of a DrawElements, you mean having a
DrawElements with as many elements as vertices, and placing the index of
the vertices in back to front order in there?
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?
3) Break your particles into clumbs and the let the OSG does it's usual depth
sorting. Results will be better than crap, but possibly not that
much better...
Heh, yeah. One point sprite per Geometry :-)
4) Have your particles entered into an osg::Geometry/custom geometry, and have
a drawImplementation/draw callback that selects an appropriate DrawElements
that has been presorted for the viewing direction the viewing is currently
looking from. Such an approach will work best with static data though.
Yeah, it's dynamic data so not that great.
Thanks a lot for the suggestions, some food for thought in there.
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
