Hi JS, On Tue, Jun 15, 2010 at 7:16 PM, Jean-Sébastien Guay <[email protected]> wrote: > 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.
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. > 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? Yes that's the idea. > 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. >> 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 :-) 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. -- 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. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
