<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Thanks Wojciech and Robert,<br>
You have given me some things to think about.<br>
I used the DB variant because my dynamic terrain geometry (Virtual
Terrain Project) is almost always far bigger than the area in which I
am interested in drawing good (building) shadows resulting in blocky
shadows in most of the other methods.<br>
I will check whether the way we set up attributes in the graph could be
affecting this. Though I don't rememeber using protected atrributes
anywhere. I must admit that I have been puzzled in the past when I have
added things that use shaders into our scenes about how much the frame
rate slows. I did some experiments recently trying to ensure that fast
paths and VBOs were used throughout but they did not seem to improve
things. Maybe there is a clue for me somewhere in that, and the shadow
stuff is really just highlighting an already existing performance
bottleneck in our scenes.<br>
Wojciech Lewandowski wrote:
<blockquote cite="mid:85421948F94749E0BBA02FF80A1A43C1@ai.com.pl"
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.5726" name="GENERATOR">
  <div><font face="Arial" size="2">Hi Guys,</font></div>
  <div> </div>
  <div><font face="Arial" size="2">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. </font></div>
  <div> </div>
  <div><font face="Arial" size="2">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.  </font></div>
  <div> </div>
  <div><font face="Arial" size="2">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.</font></div>
  <div> </div>
  <div><font face="Arial" size="2">Cheers,</font></div>
  <div><font face="Arial" size="2">Wojetek Lewandowski</font></div>
  <div> </div>
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">-----
Original Message ----- </div>
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>From:</b>
    <a moz-do-not-send="true" title="robert.osfield@gmail.com"
 href="mailto:robert.osfield@gmail.com">Robert Osfield</a> </div>
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>To:</b>
    <a moz-do-not-send="true" title="osg-users@lists.openscenegraph.org"
 href="mailto:osg-users@lists.openscenegraph.org">OpenSceneGraph Users</a>
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>Sent:</b>
Wednesday, March 25, 2009 1:47 PM</div>
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>Subject:</b>
Re: [osg-users] Big performance hit when using shadows</div>
Hi Roger,<br>
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 :-)<br>
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.<br>
Also try the standard osgshadow example:<br>
   osgshadow -4 --lispsm<br>
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.<br>
    <div class="gmail_quote">2009/3/25 Roger James <span dir="ltr"><<a
 moz-do-not-send="true" href="mailto:roger@beardandsandals.co.uk">roger@beardandsandals.co.uk</a>></span><br>
    <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
      <div text="#000000" bgcolor="#ffffff">Hi,<br>
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.<br>
Is anyone else experiencing these levels of performance hit.<br>
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?<br>
Any help or comments gratefully received!<br>
My apologies for the vagueness of the question, but I do not know where
to start.<br>