[osg-users] Shadow Map

Cedric Pinson mornifle at plopbyte.net
Wed Sep 3 04:47:07 PDT 2008

about the gauge i can't check right now, but i remember that it was the 
gpu gauge that increase or decrease. It just means that adding or not 
the shader instruction to fetch the pixel in the shadow map make a 
difference. Another test that could be interesting, is if it's the 
shadowSampler that cost or if a regular texture fetch would have the 
same effect.

Anyway it makes senses to avoid this fetch if the gpu has a bottleneck 
on this part.
Thanks you for all informations


Wojciech Lewandowski wrote:
> Hi Cedric,
> I have not answered your question about StandardShadowMap. Its 
> available in osg-submissions forum as a part of ViewDependentShadows 
> package.
> http://tinyurl.com/66h9z6
> or
> http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2008-August/002189.html 
> I have sent ViewDependentShadows package for evaluation and possible 
> inclusion  in osgShadow. One of the classes is StandardShadowMap. But 
> in this version it does not handle ReceivingShadow mask differently 
> than osgShadow::ShadowMap. One benefit for you would be cleanaer 
> separation of steps performed during cull by ShadowMap technique. It 
> would be potentialy simpler to derive some other class  from 
> StandardShadowMap.
> Cheers,
> Wojtek
> ----- Original Message ----- From: "Cedric Pinson" 
> <mornifle at plopbyte.net>
> To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
> Sent: Wednesday, September 03, 2008 10:56 AM
> Subject: Re: [osg-users] Shadow Map
> 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
> shadowscene
> 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
> implementation.
> Is there a version of the futur ShadowMapStandard available on the web ?
> Cheers
> Cedric
> 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 http://www.plopbyte.net

More information about the osg-users mailing list