[osg-users] Shadow Map

Wojciech Lewandowski lewandowski at ai.com.pl
Wed Sep 3 02:32:02 PDT 2008

Hi Cedric,

Interesting observations. In a sense ShadowMap technique forks cull 
traversal. One cull traversal build render bins to draw the scene on the 
screen the other traversal bulids render bins for shadow map camera.  By 
removing a number of objects from this second traversal you should be able 
to get some more fps. So it was expected. But there should be no real gain 
on draw traversal unless you stopped rendering shadow casters on the screen 
(they are only rendered into shadow map). Can you check on the bars which 
traversal benefits the most ?


Hi guys,

About the performance i guessed it was not free, but i did not have an
idea about the cost, so i made a little test in my application, I hacked
shadowmap.cpp to render the shadowmap only on node with the nodemask
receiveShadow then other are renderer as if they were outside the

The first scene:
Hacked shadowmap
- the earth model - receive shadow
- 100 * dumptruck - cast shadow but does not receive
result = 63fps

No hacked Version:
- the earth model - receive shadow
- 100 * dumptruck - cast shadow and receiveshadow
result = 38fps

The second scene:
Hacked shadowmap
- the earth model - receive shadow
- 100 * cow - cast shadow but does not receive
result = 82fps

The second test was with regular shadowmap implementation so:
No hacked Version:
- the earth model - receive shadow
- 100 * cow - cast shadow and receiveshadow
result = 102fps

the test was on GeForce 8600M GT - 512 MB - dual core 2 2.4Ghz

Then it's just mean that it's not so free if you have a lot of object
shadowed. It's a quick test so maybe it's not accurate
but it think it gives an idea. But the other argument to control the
self shadowing feature it's to just to control if you
want to see shadow or not on object. Sometime in non realistic rendering
or special rendering you want to control
what cast and receive shadow. But i know it's not most of usage so i
understand ShadowMap is not designed for that.

Any way it was interesting to understand the current ShadowMap

Is there a version of the futur ShadowMapStandard available on the web ?


Jean-Sébastien Guay wrote:
> Hello Cedric,
>> With this solution an object that cast shadow will get it's own shadow 
>> isn't it , i know in most of the case it's what
>> you want but i would like to avoid when i can for performance reason.
>> I would like something like a list a of caster and a list of receiver. 
>> Maybe i could just write a shadowmap
>> technic that allow that.
> The osgShadow::ShadowMap technique has just not been designed to do that. 
> You have the option of either:
> 1. Casts and receives : object is under ShadowedScene, and has the correct 
> nodemasks
> 2. Does not cast but receives : object is under ShadowedScene, and has 
> ~CastsShadow nodemask
> 3. Does not cast, does not receive : object is not under ShadowedScene.
> Doing anything more would require some changes. You can always subclass 
> ShadowMap to do it, but as the class stands it's not very useful since 
> you'll need to copy-paste most of it anyways because it was not really 
> designed to be subclassed (all the work is done in the cull() method). I 
> think the upcoming improvements by Wojtek will make this sort of thing 
> much more doable.
> But in any case, I don't really see why you don't want an object to 
> self-shadow. In a shadow map technique, it does not involve any additional 
> cost. If the object casts shadows on other objects, then it's already part 
> of the ShadowMap RTT, and thus, where it casts its shadows has no effect 
> on performance (at least as far as I know, perhaps I'll learn something 
> new...).
> Hope this helps,
> J-S

+33 (0) 6 63 20 03 56  Cedric Pinson mailto:mornifle at plopbyte.net 

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

More information about the osg-users mailing list