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.
Cheers,
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.
Robert.
2009/3/25 Roger James <[email protected]>
Hi,
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.
Roger
_______________________________________________
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
