HI Julien, The state sorting happens implicitly when the OSG populates the osgUtil::StateGraph so that no additional sorting stage is required for SORT_BY_STATE mode.
I'm very surprised to see this behavior as a default. > I presume you are surprised by the lack of explicit code doing the sorting making it look like SORT_BY_STATE is a non op. But now you know what is actually happening hopefully you'll trust the OSG is doing the right thing by default. > //fine grained sorting by state > > // appears to cost more to do than it saves in draw. > > Does RenderBin sorting can't be threaded in osg model? > What combinations work most efficiently depend upon the natural of the scene graph being used. In general you want to set up the scene graph so you are sharing as much StateAttribute and StateSet's as possible to make coarsed grained state sorting and lazy state updating as efficient as possible and not require fine grained state sorting. As for threading out yet another item of work, well in this instance I don't expect it to be worth it. Complexity vs Benefit is crucial element of software development. Typically with scene graphs you get far more benefit from building an efficient scene graph than trying to fix a poorly conditioned scene graph with complex software engineering. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
