R: R: [Opensg-users] rendering performance and optimization

[Enrico Borrione]

Hi andreas, dirk, and all opensg users!   First of all, thanks for the hast response. As soon as I will have a spare moment, I will fetch me the new cvs version of opensg.   Talking of performance drop, I have another curious behaviour to report: looking for some speed improvement, I added to my code a hand made backface culling:     void main() { . . . scene = SceneFileHandler::the().read(argv[1]); PolygonChunkPtr polyChunk2 = PolygonChunk::create();       beginEditCP(polyChunk2);             polyChunk2->setCullFace( GL_BACK ); endEditCP(polyChunk2); addMaterial( scene, polyChunk2, 0 ); . . . }   void addMaterial( OSG::NodePtr curNode, osg::StateChunkPtr mat, int sortKey ) {       bool visitato = false;       static int level = 0;         for( int nChild = 0; nChild <= curNode->getNChildren() && visitato == false ; ++nChild )       {             if (curNode->getCore()->getType().isDerivedFrom( MaterialGroup::getClassType()))             {                   MaterialGroupPtr group = MaterialGroupPtr::dcast(curNode->getCore());                   ChunkMaterialPtr material = ChunkMaterialPtr::dcast(group->getMaterial());                   beginEditCP(material);                               material->setSortKey( sortKey );                               if( sortKey < 0 )                               printf( "debug sort key set!\n");                               material->addChunk(mat);                   endEditCP(material);             }             else if (curNode->getCore()->getType().isDerivedFrom( Geometry::getClassType()))             {                   GeometryPtr geo = GeometryPtr::dcast(curNode->getCore());                   ChunkMaterialPtr material = ChunkMaterialPtr::dcast(geo->getMaterial());                   if( material != NullFC ){                     beginEditCP(material);                                 material->setSortKey( sortKey );                                 if( sortKey < 0 ) printf( "debug sort key set!\n");                                 material->addChunk(mat);                     endEditCP(material);                   }             }               level++;             if ( nChild < curNode->getNChildren() )                   addMaterial(curNode->getChild(nChild), mat, sortKey);               if ( nChild >=  curNode->getNChildren() -1 )                   visitato = true;             level--;       } }     When I execute my application, the performances drop like they used to with the depth sorting of the graph… Any idea about this strange behaviour? The backface culling should likely improve the speed of the app…   thanks again, c ya Enrico     -----Messaggio originale----- Da: [EMAIL PROTECTED] [mailto:opensg-users-admin@lists.sourceforge.net] Per conto di Andreas Zieringer Inviato: domenica 21 maggio 2006 18.04 A: opensg-users@lists.sourceforge.net Oggetto: Re: R: [Opensg-users] rendering performance and optimization   Hi Dirk,   thanks for the hint the code was a bit suboptimal ;-) I fixed it.   Andreas   >    Hi Enrico, > > Enrico Borrione wrote: > >> Hi andreas, >> thanks for the fast answer. I tried your suggestion, >> but my application behaves weirdly. For debugging >> purposes I added a SimpleStatisticsForeground, >> so now I am reporting to you the output. >>  >> If I do not activate the occlusion culling, it says: >>  >> Fps:                38     (I am not using any shader) >> Material Changes:     10 >> Nodes Drawn:         ~14000 >> Triangles Drawn:         ~64000 >> Primitives Groups:     ~24000 >> Vertices Transformed:     ~114000 >>  >> If I switch on the occlusion culling, >> The speed drops and: >>  >> Fps:                2.4 >> Tested Nodes:         15 >> Culled Nodes:         ~14000 >> Material Changes:     ~11000 >> Matrix Changes:         ~6000 >> Nodes Drawn:         256 >> Triangles Drawn:         ~7000 >> Primitives Groups:     ~600 >> Vertices Transformed:     ~8000 >>  >> So the number of rendered primitives is dramatically reduced... >> But now most of the time is spent in material / state changing. >>  >> Any clues about this strange behaviour? >>  > The basic behaviour is not surprising, given that the front-to-back > ordering disables the state change minimization. However, 11000 > material changes for 256 Nodes is just wrong, there is something amiss > in the OC code. > > Andreas, can you take a look to make sure that only visible nodes' > materials are activated? > > Yours > >    Dirk > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users > >       ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users