If you want to know in detail what each optimization the osgUtil::Optimizer does you'll probably have to read the code, but the doxygen documentation has some info (scroll down to the Classes section):
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01526.html Alex ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Simon Loic Sent: Tuesday, February 10, 2009 2:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? One thing I would like to try before balancing the scene graph is to use osgUtil::Optimizer in order to diagnose the problem of my scene graph. Do you think this make sense? If yes can someone explain me quickly the effect of the different optimizer options or just point me to a document which does so. Thanks a lot. On Tue, Feb 10, 2009 at 10:46 PM, Simon Loic <[email protected]> wrote: I'm quite interesting in getting my scenegraph more balanced scenegraph. I will take the time to think about it (and probably ask for help then). Concerning the _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS I didn't get how to generate the include/OpenThreads/Config file. Anyway, I don't get neither how it can come into play as I'm profiling with the SingleThreaded option and the results are too bad. regards, On Tue, Feb 10, 2009 at 5:32 PM, Robert Osfield <[email protected]> wrote: Hi Simon, Like Alex I recommend that you have a look at whether your build is using atomic ref counts. Second up, your explanation of your scene graphs suggest to me that is very poorly balanced. You cull/draw times are all very long, even for complex scenes I would expect cull and draw times 1/10th of these. Lots of PAT's all under a single Group node is really badly balanced - you should try to create a quad tree structure as this improves cull performance significantly as how subgraphs containing thousands of nodes can be culled in a single op. Also see if you can use an design that doesn't rely heavily of PAT's, as each transform in your scene requires the view frustum to be transformed into the local coords of the PAT, which is relative expensive operation. Robert. On Tue, Feb 10, 2009 at 8:50 AM, Simon Loic <[email protected]> wrote: > I think I have a problem similar to Alex one. > The stats I get follow : > > MultiThreaded/SingleThreaded > Cull Time: 40/33 > Draw Time: 55/52 > GPU Time: 85/85 > > I also attached a callgrind output (you can use kcachegrind to analyse it) > where it seems that the osgUtil::SceneView::cull() costs 70% of > osgViewer::Renderer::cull_draw() while osgUtil::SceneView::draw() counts for > only 30% !! However I'm not much aware with the way osgViewer works, yet I > find this result weird in comparison with the stats results. > > In my case I have a scene graph composed of many nodes (i don't think I can > post the .osg which is 16MB). The strucuture is not complex : I have a > shadow scene as root with as child a group (the real root of the graph some > how). Then the root is connected to plenty of PositionAttitudeTransfoms > having each one a child which is a geode. > > In fact the geode are quite complex polygonal meshes. So I would expect that > the draw part is more costly than the draw part. > I hope this can help to see what is wrong for Alex and for me. > > > On Tue, Feb 10, 2009 at 7:54 AM, J.P. Delport <[email protected]> wrote: >> >> Hi, >> >> Mathias Fröhlich wrote: >>> >>> Hi, >>> >>> On Monday 09 February 2009 23:54, Pecoraro, Alexander N wrote: >>>> >>>> On Linux this translated to "-O3 -DNDEBUG" (at least that's what >>>> cmake-gui says is defined for the CMAKE_CXX_FLAGS_RELEASE variable). >>> >>> May be I know cmake to little, but the only way to really make sure I got >>> cmake correct was to set CMAKE_VERBOSE_MAKEFILE=TRUE and see how the build >>> scripts really call the compiler. >> >> you can also run make <other options> VERBOSE=1 >> on the normal cmake generated Makefile. >> >> jp >> >>> >>> Robert, >>> I know that it is a matter of taste if one sets this flag. But may be it >>> will help people to catch unoptimized builds due to the possible >>> intransparency of cmakes compile flags handling. So should that be on by >>> default? >>> >>> Greetings >>> >>> Mathias >>> >> >> -- >> This message is subject to the CSIR's copyright terms and conditions, >> e-mail legal notice, and implemented Open Document Format (ODF) standard. >> The full disclaimer details can be found at >> http://www.csir.co.za/disclaimer.html. >> >> This message has been scanned for viruses and dangerous content by >> MailScanner, and is believed to be clean. MailScanner thanks Transtec >> Computers for their support. >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > Loïc Simon > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon -- Loïc Simon
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
