[osg-users] Big performance hit when using shadows

Wojciech Lewandowski lewandowski at ai.com.pl
Wed Mar 25 08:31:31 PDT 2009

Hi Guys,

I usually get half of the initial framerate with LISPSM DB shadows. DB variant does one extra pass (beyond shadow map pass) to prerender the scene and compute minimal shadow bounds.This may be the culprit in your case. Result of this phase, the image with depths recorded at some smaller resultion, is scanned (CPU unfortuanately) and polytope around shadow receiving scene computed. Obvious performance penalty caused here is related to reading prerendered image to main memory and computing bounding box around points associated with every depth rendered. This is a step I would like to see computed on GPU but I was not sure how could I implement this without number of extra passes. 

I made an attempt to override most of the StateAttributes with minimal set of simple attributes to avoid unnecessary state changes this depth prernder phase and shadow map rendering phase. But I could imagine that if someone somehow (PROTECTED attributes ?) managed to avoid this override on some of their states it may cause longer than normal rendering.  

You may try LISPSM_CB and see if this causes the same loss of framerate. CB flavour computes shadwed scene by scanning render bin and computes bounding boxes around render leaves selected for draw phase. This method should provide similar precision as DB if your drawables are fairly small. But if some of the drawables extend far beyond visible scene, computed shadowed voulem will be much larger than DB result. And this could eventually greatly degrade shadow generation precision.

Wojetek Lewandowski

  ----- Original Message ----- 
  From: Robert Osfield 
  To: OpenSceneGraph Users 
  Sent: Wednesday, March 25, 2009 1:47 PM
  Subject: Re: [osg-users] Big performance hit when using shadows

  Hi Roger,

  I haven't seen such great performance hits in my own testing, but I haven't pushed things too hard on the shadows front so perhaps I just haven't tested hard enough :-)

  At your end you need to look into what the performance bottleneck is, bring up the on screen stats and the look at the sizes of the update, cull, draw and GPU draw costs, comparing between the scene with shadows and the one without.

  Also try the standard osgshadow example:

     osgshadow -4 --lispsm

  For this scene I get a solid 60Hz, update and cull and GPU draw are all pretty low, but curiously the draw dispatch is locked out at 16ms which suggests that the draw is blocking on the OpenGL FIFO.


  2009/3/25 Roger James <roger at beardandsandals.co.uk>


    I have been doing some tests using the minimal draw bounds LISPSM implementation. I find that when the shadow node is inserted in the graph my frame rates go from 60 fps (vsync) down to less then 10 fps. I have verfified this on a number of different machine configurations with varying levels of graphic card capability.  The original scene graph uses fixed pipeline functionality only, so the the introduction of the shadow node is turning on programmable functionality and some extra traverses of parts of the scene graph.

    Is anyone else experiencing these levels of performance hit.

    I am wondering if there is some kind of fundamental bottleneck in the way my graph is constructed that is really being exacerbated when the programmable pipeline is active. Is this a possibility? What sort of things should I be looking for?

    Any help or comments gratefully received!

    My apologies for the vagueness of the question, but I do not know where to start.


    osg-users mailing list
    osg-users at lists.openscenegraph.org


  osg-users mailing list
  osg-users at lists.openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20090325/28a633a4/attachment-0003.htm>

More information about the osg-users mailing list