[osg-users] ShadowMap problem...

[Wyatt Earp]

I have taken the code I think I need from the osgShadow example and tried to add shadows to my existing application.    The problem is that the shadow map displayed in the debug window is just a gray-ish circle centered on a white-ish background, nothing at all what  I expected and no details that look anything like the objects in my scene.  This remains the same regardless of whare I put my light source.  Any suggestions? 

 

My code is as follows:

W

 

 

osgViewer::CompositeViewer viewer;

osgViewer::View* view = new osgViewer::View;

viewer.addView(view);

view->setUpViewInWindow(50, 50, currentWidth, currentHeight, 0);

 

osg::ref_ptr<osgShadow::ShadowedScene> shadowedScene = new osgShadow::ShadowedScene;

 

shadowedScene->setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);

shadowedScene->setCastsShadowTraversalMask(CastsShadowTraversalMask);

 

osg::ref_ptr<osgShadow::ShadowMap> sm = new osgShadow::ShadowMap;

shadowedScene->setShadowTechnique(sm.get());

 

int mapres = 1024;

sm->setTextureSize(osg::Vec2s(mapres,mapres));

 

m_World = new osg::Group;

 

// add some things to m_World…. Removed for brevity sake

 

 

// get the bounds of the model.

osg::ComputeBoundsVisitor cbbv;

m_World->accept(cbbv);

osg::BoundingBox bb = cbbv.getBoundingBox();

 

osg::Vec4 lightpos;

 

viewer.getView(0)->getEventHandlers().push_front(new osgViewer::StatsHandler);

viewer.getView(0)->getEventHandlers().push_front(mykey);

 

std::vector<osg::Camera*> cameras;

viewer.getCameras(cameras);

cameras[0]->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

cameras[0]->setProjectionMatrixAsPerspective(40.0, 1.333333333, 1.0, SKYDOME_RANGE*1.1f);

 

bool postionalLight = true;

if (postionalLight)

{

    lightpos.set(bb.center().x(), bb.center().y(), bb.zMax() + bb.radius()*2.0f  ,1.0f);

}

else

{

    lightpos.set(0.5f,0.25f,0.8f,0.0f);

}

 

osg::ref_ptr<osg::LightSource> ls = new osg::LightSource;

ls->getLight()->setPosition(lightpos);

 

shadowedScene->addChild((osg::Node*)m_World);

shadowedScene->addChild(ls.get());

 

bool updateLightPosition = true;

 

viewer.realize();

 

viewer.getView(0)->setSceneData(shadowedScene.get());

 

 bool debugHUD = true;

 

if(debugHUD)

{

    osgViewer::Viewer::Windows windows;

    viewer.getWindows(windows);

 

    if (windows.empty()) return 1;

 

    osgShadow::ShadowMap* sm = dynamic_cast<osgShadow::ShadowMap*>(shadowedScene->getShadowTechnique());

    if( sm ) {

       osg::ref_ptr<osg::Camera> hudCamera = sm->makeDebugHUD();

 

       // set up cameras to rendering on the first window available.

       hudCamera->setGraphicsContext(windows[0]);

       hudCamera->setViewport(0,0,windows[0]->getTraits()->width, windows[0]->getTraits()->height);

 

       viewer.getView(0)->addSlave(hudCamera.get(), false);

    }

}

 

// display the help

key->showHelp();

 

while( !viewer.done() )

{

    cameras[0]->setViewMatrix(key->getViewMat());

 

    if (updateLightPosition)

    {

        float t = viewer.getFrameStamp()->getSimulationTime();

        if (postionalLight)

        {

            lightpos.set(bb.center().x()+sinf(t)*bb.radius(), bb.center().y() + cosf(t)*bb.radius(), bb.zMax() + bb.radius()*3.0f  ,1.0f);

        }

        else

        {

            lightpos.set(sinf(t),cosf(t),1.0f,0.0f);

        }

 

        ls->getLight()->setPosition(lightpos);

 

        osg::Vec3f lightDir(-lightpos.x(),-lightpos.y(),-lightpos.z());

 

        lightDir.normalize();

        ls->getLight()->setDirection(lightDir);

    }

 

    viewer.frame();

}

 

 

 

I also must add that I am using my own shaders and have reproduced the shadowmap shader code as follows:

 

 

uniform sampler2D osgShadow_baseTexture;

uniform sampler2DShadow osgShadow_shadowTexture;

uniform vec2 osgShadow_ambientBias;

 

vec4 myCalculations()

{

   // Details Omitted;

}

 

void main (void)

{

   //  My shader code details omitted

 

   // shadow mapping

   vec4 color = gl_Color * texture2D( osgShadow_baseTexture, gl_TexCoord[0].xy );

   gl_FragColor = color * (osgShadow_ambientBias.x + shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[1] ) * osgShadow_ambientBias.y);

}

 

 

 

 

[Jean-Sébastien Guay]

Hi Wyatt,

> Any suggestions?

I haven't tried your code, but I don't see you calling
ShadowMap::setLight() anywhere... Try to add this once your light source
is initialized:

sm->setLight(ls->getLight());

Other than that, at first glance your code seems OK.

Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Wyatt Earp]

Thanks, That seem to make some change, instead of a grayish circle, I now
see a moving roundish object...
W

[Jean-Sébastien Guay]

Hi Wyatt,

> Thanks, That seem to make some change, instead of a grayish circle, I now
> see a moving roundish object...

Sounds familiar...

Han Solo: [flying across the deserts of Tatooine] I think my eyes are
getting better. Instead of a big dark blur, I see a big bright blur.

http://www.imdb.com/character/ch0000002/quotes

</goofing off>

Give me a minute, I'll try it out and see.

Just have to ask, if you try with only one object and a ground plane (a
really simple scene) do you get the same results?

[Wyatt Earp]

No but I'll try it...

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Tuesday, November 10, 2009 2:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

[Jean-Sébastien Guay]

Hi Wyatt,

> Just have to ask, if you try with only one object and a ground plane (a
> really simple scene) do you get the same results?

I just tested, and your code seems to work. I've attached a source file
which is the osgshadow example, with the main() commented out and your
code in its place. Have a look, the only changes were to put the
ModelThree scene as child of your m_World group and to make sure I had a
manipulator, and make everything compile...

You seem to be using a skydome (based on a variable called SKYDOME_RANGE
in the code). You did set your skydome's node mask to ~cast right?
Otherwise what you're seeing is probably your skydome's shadow being
cast over everything... That's one thing about using osgShadow, you need
to make sure things that you don't want to cast shadows don't have the
cast shadow bit in their node mask. Also HUDs should be set that way.
Keep an iron grip on your node masks or you'll have unpleasant
surprises... :-)

The receive shadow node mask is not used for ShadowMap classes, but you
can implement a node that doesn't receive shadows by adding a case in
your shader (a test on a boolean uniform that skips the shadow test) and
set that uniform to true at your scene's root and false for each node
that you don't want to receive shadows.

And btw, osgShadow::ShadowMap is not really designed for positional
lights, because they're omnidirectional and would need 6 full-scene RTT
passes (like a cube map) to be totally accurate. I think (IIRC)
osgShadow::ShadowMap and the ViewDependentShadow classes try to
approximate a directional in that case, but the approximation breaks
down if the light source is positioned inside the bounding box of the
scene... You're better off either approximating the sun with a
directional, or using a spot light for an interior scene.

Hope this helps,

[Wyatt Earp]

Getting closer to having this working like I think it should, but I have
noticed something.

When I have one or two objects, say the size of a car, or truck, only. The
shadow map looks correct. But when I add my terrain which is approximately x
= 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map.

Similarly, if I increase the length and width of the bottom box in the
osgShadow example, I no longer see the other objects in the shadow map.

I assume I am running into some shadow map texture resolution limit or
something. What is going on?

Tnanks,
W

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Tuesday, November 10, 2009 3:08 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

Hi Wyatt,

Hope this helps,

_______________________________________________

[Wyatt Earp]

My shadow map is looking mostly correct now after making changes to light
type, position etc. However shadows are not appearing in the final
rendering. The app I am trying to add shadow mapping to uses textures bound
to tex units 0-3. I noticed in the ShadowMap class there were methods for
setting the texture unit and wondered if this possibly why I am not seeing
the shadows. That is, is my use of tex units 0-3 conflicting with
ShadowMaps use of texture units and should I reassign one or the others
texture units?

W

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Tuesday, November 10, 2009 3:08 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

Hi Wyatt,

Hope this helps,

_______________________________________________

[Jean-Sébastien Guay]

Hi Wyatt,

> When I have one or two objects, say the size of a car, or truck, only. The
> shadow map looks correct. But when I add my terrain which is approximately x
> = 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map.
>
> Similarly, if I increase the length and width of the bottom box in the
> osgShadow example, I no longer see the other objects in the shadow map.
>
> I assume I am running into some shadow map texture resolution limit or
> something. What is going on?

Yep, Most probable. osgShadow::ShadowMap can't help you there, but there
are a few things you can do to mitigate the problem.

* First, don't set your terrain to cast shadow (if it's mostly flat
you'd never see its shadow anyways)
* Second, make sure all the objects you set to cast shadow are in a
small area. If an object leaves the area of focus, remove its cast
shadow bit from its node mask.
* Third, increase the shadow map resolution as much as you can (on some
cards, 4096x4096 is the biggest you can go, on some others it's 2048x2048)

But if you want better results, switch to one of the ViewDependentShadow
techniques that are in OSG 2.8+ (for example
osgShadow::LightSpacePerspectiveShadowMap). These will consider the
camera's view volume and only calculate shadows for this area
automatically, so if you're looking at a relatively small portion of
your scene it will give much better results. Though they have some
artifacts in some situations too... Nothing is perfect, it's always a
trade-off.

> My shadow map is looking mostly correct now after making changes to light
> type, position etc. However shadows are not appearing in the final
> rendering. The app I am trying to add shadow mapping to uses textures bound
> to tex units 0-3. I noticed in the ShadowMap class there were methods for
> setting the texture unit and wondered if this possibly why I am not seeing
> the shadows. That is, is my use of tex units 0-3 conflicting with
> ShadowMaps use of texture units and should I reassign one or the others
> texture units?

Most probably, ShadowMap uses texture unit 1 by default for the shadow
map. Call osgShadow::ShadowMap::setTextureUnit() to set the texture unit
you want the shadow map to use (for example 4, or 7 to give yourself
some breathing room), and use that same texture unit in your shadow
shaders when you get to the point of generating texture coordinates and
doing the shadow lookup too. There's a similar method in
osgShadow::LightSpacePerspectiveShadowMap.

[Wyatt Earp]

Yes this all helps greatly.. I really appreciate the help you have provided.
Thanks,
W

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Wednesday, November 11, 2009 8:04 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

[Wyatt Earp]

BTW, 2 more questions....

1. Is there a way I can query the number of texture units available on my
GPU via an OSG call?
2. Is there a list, other than the osgShadow programming guide of shadowmap
techniques, specifically ViewDependentShadow techniques?

W

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay

Sent: Wednesday, November 11, 2009 8:04 AM

To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

[Jean-Sébastien Guay]

Hi Wyatt,

> 1. Is there a way I can query the number of texture units available on my
> GPU via an OSG call?

A Google search turned up glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB). Also
searching the OSG headers, I found
osg::Texture::Extensions::numTextureUnits() which returns a GLint (int).
Look at the source to find out where the value will be initialized or
how to initialize it yourself.

I generally don't bother to query and use 8 (0-7) as a number that's
supported pretty much everywhere.

> 2. Is there a list, other than the osgShadow programming guide of shadowmap
> techniques, specifically ViewDependentShadow techniques?

The source/headers... And the mailing list archives.

The three usable types are:

class LightSpacePerspectiveShadowMapDB /*...*/ {};
class LightSpacePerspectiveShadowMapCB /*...*/ {};
class LightSpacePerspectiveShadowMapVB /*...*/ {};

And LightSpacePerspectiveShadowMap is an alias for
LightSpacePerspectiveShadowMapDB :

typedef LightSpacePerspectiveShadowMapDB LightSpacePerspectiveShadowMap;

And also StandardShadowMap is usable, but it's not view-dependent, so
it's pretty much a direct replacement for osgShadow::ShadowMap but in
the same class hierarchy as the LightSpace* classes.

[Wyatt Earp]

I have changed to a LISPSM shadow technique.
I have removed the cast bit from my terrain.
The only two objects I have set cast shadow are close together.
My texture size is 2048 x 2048.
Not seeing shadows on the terrain from my objects.
Changed shadowTexture unit to 7.
Should basetexture be 0 still?

W

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay

Sent: Wednesday, November 11, 2009 8:04 AM

To: OpenSceneGraph Users
Subject: Re: [osg-users] ShadowMap problem...

[Jean-Sébastien Guay]

Hi Wyatt,

> I have changed to a LISPSM shadow technique.

OK.

> I have removed the cast bit from my terrain.
> The only two objects I have set cast shadow are close together.

This should not need to be done when using LISPSM. It's view-dependent,
so you don't need to make sure that the shadow map is applied to a small
part of the scene as you did with the normal ShadowMap. Still, it
doesn't hurt if you don't need shadows cast by your terrain anyways.

> My texture size is 2048 x 2048.
> Not seeing shadows on the terrain from my objects.

Did you check the debugHUD (with LISPSM it's as easy as
shadowTechnique->setDebugDraw(true) )? Does it show something that looks
valid?

Note that LISPSM's shaders are different than ShadowMap's shaders that
your used before. It uses a different name for the shadow map sampler,
and by default it separates the shaders into main and shadow parts,
though you can still disable the shaders that LISPSM adds and use your
own (make sure to use the right sampler and uniform names in your
shader). Check the source in StandardShadowMap.cpp to see what the
shaders look like.

> Changed shadowTexture unit to 7.
> Should basetexture be 0 still?

The base texture unit is just used by the shaders that LISPSM sets by
default. If you're disabling those and using your own (which you surely
do if you're using units 0-3 for some effects), then don't worry about it.

[Wojciech Lewandowski]

Hi Guys,

MinimalShadowMap
MinimalCullBoundsShadowMap
MinimalDrawBoundsShadowMap
could be useful too sometimes, they take advantage of the same shadow volume
optimization methods as LispSM flavours, but not use skewed projection like
LispSM. This skewed projection is sometimes a problem when used with non
directional lights. It may also bring trouble when one wants to mix smooth
shadows with ViewDependentShadowMap techniques. So in the end all the
techniques stemming from ViewDependentShadowTechnique have their advantages
and are definitely not abstract (excluding maybe DebugShadowMap which
provides a bottom layer with debuging methods).

Cheers,
Wojtek Lewandowski

--------------------------------------------------
From: "Jean-Sébastien Guay" <jean-seba...@cm-labs.com>
Sent: Wednesday, November 11, 2009 5:26 PM
To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>

Subject: Re: [osg-users] ShadowMap problem...

> Hi Wyatt,

[Wyatt Earp]

> Did you check the debugHUD (with LISPSM it's as easy as
> shadowTechnique->setDebugDraw(true) )? Does it show something that
> looks valid?

I am not sure... With the debugHUD in the ShadowMap example, there was just
a window which appeared to display the shadow map in gray-scale, but in the
LISPSM example, there appears to be two sub-windows in the debughud window
(not in gray-scale). What are these displaying?

>
> Note that LISPSM's shaders are different than ShadowMap's shaders that
> your used before. It uses a different name for the shadow map sampler,
> and by default it separates the shaders into main and shadow parts,
> though you can still disable the shaders that LISPSM adds and use your
> own (make sure to use the right sampler and uniform names in your
> shader). Check the source in StandardShadowMap.cpp to see what the
> shaders look like.

I found the shader source, in StandardShadowMap::StandardShadowMap. I am a
bit confused about how to use the osgShadow in my app if I already have
shaders in my app.

The osgShadow programmers guide says

" What if my objects already have a shader applied to them?
* That shader also needs to implement shadow mapping. See the top of
src/osgShadow/ShadowMap.cpp for the basic shader, and use that in your
shader (keep the same names for the variables too)."

Am I supposed to, basically, copy the shader code from StandardShader map
and add it to my shaders and turn off the LISPSM shaders?

W

[Wojciech Lewandowski]

Hi Wyatt,

>> Did you check the debugHUD (with LISPSM it's as easy as
>> shadowTechnique->setDebugDraw(true) )? Does it show something that
>> looks valid?
>
> I am not sure... With the debugHUD in the ShadowMap example, there was
> just
> a window which appeared to display the shadow map in gray-scale, but in
> the
> LISPSM example, there appears to be two sub-windows in the debughud window
> (not in gray-scale). What are these displaying?

First square displays shadow map using pseudo coloring (if you interested
why see the comment above the shader in DebugShadowMap.cpp) second square
contains dump from predraw of you scene to very small depth texture, this
extra pre render step is used to compute visible part of scene and optimize
shadow volume. This second square is only drawn for LispsmDB &
MinimalDrawBoundsShadowMap.

>>
>> Note that LISPSM's shaders are different than ShadowMap's shaders that
>> your used before. It uses a different name for the shadow map sampler,
>> and by default it separates the shaders into main and shadow parts,
>> though you can still disable the shaders that LISPSM adds and use your
>> own (make sure to use the right sampler and uniform names in your
>> shader). Check the source in StandardShadowMap.cpp to see what the
>> shaders look like.
>

> [..]

>
> Am I supposed to, basically, copy the shader code from StandardShader map
> and add it to my shaders and turn off the LISPSM shaders?

Generally yes, But don't turn them off but rather alter them with your
modified shaders.

WL

[Jean-Sébastien Guay]

Hi Wyatt,

> With the debugHUD in the ShadowMap example, there was just
> a window which appeared to display the shadow map in gray-scale, but in the
> LISPSM example, there appears to be two sub-windows in the debughud window
> (not in gray-scale). What are these displaying?

The left side is the shadow map itself, and the right side is a render
of the bounds analysis render pass (the LightSpacePerspectiveShadowMapDB
technique - Draw Bounds - makes a 64x64 render pass before the actual
shadow pass to see if the shadow map bounds can be further reduced -
Wojtek can tell you more about it, or search the archives for details).

> Am I supposed to, basically, copy the shader code from StandardShader map
> and add it to my shaders and turn off the LISPSM shaders?

You only need to use some parts, those that relate to the shadow test.
The rest of your shader can be what you want - most of the shader code
in StandardShadowMap.cpp is just standard lighting, which you might be
doing differently. You should copy the DynamicShadow function for both
vertex and fragment shader (whether you want to keep it in a function or
not, up to you) and then look at the place where it's used and do
something similar.

Read the shaders, you should understand.

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/

[Jean-Sébastien Guay]

Hi Wojtek,

> Generally yes, But don't turn them off but rather alter them with your
> modified shaders.

That's useful when the ShadowedScene is the root of the scene, and your
entire scene can be rendered with a single shader (or uber-shader with
uniforms to select different code paths). But in some cases that might
not be the case.

I find it more convenient to disable the ShadowTechnique's shaders and
just place my own shaders at the root of the scene. Also others may
customize the way their shaders are applied to individual nodes.
Eventually I intend to start using VirtualProgram too... :-)

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/

[Wojciech Lewandowski]

>> Generally yes, But don't turn them off but rather alter them with your
>> modified shaders.
>
> That's useful when the ShadowedScene is the root of the scene, and your
> entire scene can be rendered with a single shader (or uber-shader with
> uniforms to select different code paths). But in some cases that might not
> be the case.

I see, that would work too.

> I find it more convenient to disable the ShadowTechnique's shaders and
> just place my own shaders at the root of the scene. Also others may
> customize the way their shaders are applied to individual nodes.
> Eventually I intend to start using VirtualProgram too... :-)

I really recommend it. We developed VirtualProgram for this particular
purpose ie to free user from creating all in one shader.

Wojtek

[Wyatt Earp]

I think I am about to get this straightened out...

I have implemented the LiSPPSM shadow code in my app. My scene consists of
two vehicles and a terrain. If I don't add the terrain, I can see the
shadows on the base test geometry and it looks pretty good. The base
geometry just happens to be sitting below my two vehicles. If I do add the
terrain, most of the terrain is covered by a big black square, and I no
longer see the shadows on the base geometry (I can descend below the
geometry of the terrain and see the base geometry). Is something possibly
casting a large shadow on the terrain to cause the big black square? I am
not sure what it could be since I only have the terrain, two vehicles and
the base geometry. Any suggestions?

Thx
W

> -----Original Message-----
> From: osg-user...@lists.openscenegraph.org [mailto:osg-users-
> bou...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay
> Sent: Wednesday, November 11, 2009 2:33 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] ShadowMap problem...
>

[Wyatt B. S. Earp]

I also noticed that the vehicles are all black without the terrain... i.e. just the base test texture, as though they are shadowed completely.

W

> > http://www.cm-labs.com/
> > http://whitestar02.webhop.org/
> > _______________________________________________
> > osg-users mailing list
> >

> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> > openscenegraph.org
> >
>
> _______________________________________________
> osg-users mailing list
>

> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> ------------------
> Post generated by Mail2Forum

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19582#19582

[Jean-Sébastien Guay]

Hi Wyatt,

> Any suggestions?

Not really. At this point you'll probably have to trace into OSG to make
sure the shadow map traversal is getting to the right objects (i.e. your
masks are set correctly), and check your shaders (perhaps even try with
the basic shaders that LISPSM uses by default for starters). Also, try
to start with the osgShadow example, and work up progressively to
something similar to what you have in your app, and perhaps in the
process you'll find out what's not working. If not, then at least you'll
have a small app that can demonstrate the problem, which we might be
able to help with.

Hope this helps,

[Wojciech Lewandowski]

I agree with J-S, just try loading your scene into osgshadow and see if it
works there. All black may mean anything btw, can you post a screenshot
sometimes ? You seem to be this unique type who tend to prefer thousands
words than one picture....

Wojtek

--------------------------------------------------
From: "Jean-Sébastien Guay" <jean-seba...@cm-labs.com>

Sent: Thursday, November 12, 2009 8:45 PM
To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>

Subject: Re: [osg-users] ShadowMap problem...

> Hi Wyatt,

[Wyatt Earp]

Ok... so I did what you suggested mostly... I took the osgshadow example, add my geometry and it worked.  I added another shader on the root node of the scenegraph, because in my app, I do that.  I took the shaders from ShadowMap.cpp and put them into vert/frag files and loaded them into their respective shaders.  That worked too.

 

In my application, when I load those shaders from ShadowMap.cpp and use them, I see a change in the lighting but it isn’t what I expect.  Rather than the objects casting shadows on the terrain, it looks like a shdow is being cast over the objects, but it isnt'being cast on the terrain.  The best way I can describe it is that it looks like the objects are in the sun then a cloud floats between the sun and the object...  I don’t think a picture will show what I mean, but here are 3 pictures with the shadow moving progressively to the left over the object... note the white building in the front gets darker.  But now shadows on the terrain.

 

 

 

 

 

W

 

 

 

> -----Original Message-----

> From: osg-user...@lists.openscenegraph.org [mailto:osg-users-

> bou...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay

> Sent: Thursday, November 12, 2009 1:45 PM

> To: OpenSceneGraph Users

> Subject: Re: [osg-users] ShadowMap problem...

>

> Hi Wyatt,

[Wojciech Lewandowski]

Hi Wyatt,

 

Buildings getting darker while light is moving can be a normal thing it is simply a result of normal diffuse shading. Can you move camera so close that view frustum contains a single building ?. Ideally make it look at 45 deg from a liitle above. Then make screenshot, with debugHUD. Its really important whats on debug hud display.  This will tell me alot. If you have problems with 300 kb OSG forum limit, just send this screenshot directly to my address.

 

Cheers,

Wojtek Lewandowski

[Wyatt Earp]

Thanks for the reply... I'll do that and post result.... Thanks,
W

[Wojciech Lewandowski]

Hi Wyatt,

 

Yes,thats a good picture. What it tells me:

 

1. Light node has been found and direction seem to be computed correctly.

2. Shadow map seems correct. Only back faces from light perspective are rendered.  These are the faces that are casting shadows. This is exactly what Lispsm sets.

 

Since ShadowMap rendering seems correct you most probably have an issue with application of shadow map to final scene.

 

Here is a check list to iterate.

 

1: Check your texcoords and texstages and verify if there is no conflict of some other texture with shadow map stage/coords.

2: Check your shaders if they compile and use the same shadow map uniforms /shadow coords correctly. Try turning shaders off. Lispsm shadows should work  even with fixed pipeline. Usually shadows become almost black but they are visible.

3: If you use vertex shader check materials used for terrain and buildings. Vertex shaders do not work correctly with materials using COLOR_MATERIAL attribute ie some material components are defined through vertex colors. Your material should have COLOR_MATERIAL mode set to off and diffuse/ambient/specular components should be defined in material not in promitive colors. COLOR_MATERIAL mode is notorious for the problems with shadows.  Its not supported by shaders. Works with fixed pipeline only. Best solution is to convert (osgconv) your model file into text .osg format and examine states it uses in text editor.  

 

If this does not help, consider sending a piece of your code and models.

 

Cheers,

Wojtek

 

From: Wyatt Earp

Sent: Friday, November 20, 2009 6:03 AM

To: 'OpenSceneGraph Users'

Cc: 'Wojciech Lewandowski'

Subject: RE: [osg-users] ShadowMap problem...

Is this what you meant?

Thanks,

W

[Wojciech Lewandowski]

Hi Wyatt,

 

I have sent a response from home but somehow I cannot notice it on osg-users list at work. You may ignore this post if you got earlier one.

 

Thats the screenshot I wanted. It tells me that everything is correct in shadow map generation pass. Light is found, direction seems right, shadow map contains only back faces (front faces were culled) from light perspective. Terrain is not rendered to shadow map only backfacing polygons from buildings. And thats what I would expect.

 

So at this stage everyting seems correct. Which means there a problem in shadow map application. Here is a checklist to follow:

 

1. Make sure Texture coords / Shadow Map texture stage & sampler are not conflicting with other textures. This can also refer to Shadow TexGen. Make sure you don't have other TexGen producing the coords at the same tex coord unit as shadow map coords.  Check shadow map sampler uniform names and see if your Shaders use the same names as default StandartdShadowMap shaders. 

 

2. Try turning off programmable pipeline completely (use empty program with override at root of the scene graph).  Shadows should draw something even in fixed pipeline. Shadows are usually pitch dark in fixed pipeline but they are defintiely visible. Modify shaders to output only a shadow factor on color. This way you will know if the shadow term is computed and passed correctly. If its drawn then see next point because lack of shadows may be related to improper ambient term computation.

 

3. Default StandardShadowMap and LispSM shaders treat shadow term as diffuse / specular light filter. Ie when pixel is in shadow its only lit by ambient color. If for some reason ambient is not computed properly then you may see similar issues to the ones you posted. Check terrain lighting and materials and see if they use GL_COLOR_MATERIAL attribute. GL_COLOR_MATERIAL means that some of the material components is taken from primitive/vertex colors. GL_COLOR_MATERIAL does not work with vertex shaders. So its important to use materials that have all components defined internally.

 

Hope this helps, if not, consider sending a code and models sample (you may send it directly to my email account if you want NDA ;-)

 

Cheers,

Wojtek

----- Original Message -----

From: Wyatt Earp

To: 'OpenSceneGraph Users'

Cc: 'Wojciech Lewandowski'

Sent: Friday, November 20, 2009 6:03 AM

Subject: RE: [osg-users] ShadowMap problem...

Is this what you meant?

Thanks,

W

 

 

 

[Wyatt Earp]

Trying again… looks likethe other email didn’t get through.

W

[Wyatt Earp]

Thanks for the suggestions.  I’ll go through the steps you suggested… A bit more information…

 

 

I use texture units 0-3 for my texturing.

I set the base texture unit for the shadows to 0 and the shadow texture unit to 7.

[Wyatt Earp]

Background… Trying to add light perspective shadow map shadows to my app.

 

My app already has shaders enabled.  I have two sets of shaders, each one being run for a given “mode’.  Either shadersA or shadersB runs, but not both at the same time.

 

I replace shadersB with the shaders from StandardShadowMap.cpp. 

 

These shaders, from StandardShadowMap.cpp produce shadows IF and ONLY IF I disable shadersA.  Otherwise, the result is what is shown in the image(s) included in one the previous emails.

 

shadersA uses texture units 0-6 inclusive, and TexCoord0-6.

shadersB, the ones from StandardShadowMap.cpp, uses, well, whatever it uses when I set the tex units:

 

unsigned int baseTexUnit = 0;

unsigned int shadowTexUnit = 8;

sm->setShadowTextureCoordIndex( shadowTexUnit );

sm->setShadowTextureUnit( shadowTexUnit );

sm->setBaseTextureCoordIndex( baseTexUnit );

sm->setBaseTextureUnit( baseTexUnit );

 

 

I see that in the shadow shaders, and in my shaders, both gl_MultiTexCoord0/1 are used.  Could that be one of the problems? 

 

Assuming I want to keep all my shaders the same, would I need to change anything in osgShadow node kit to resolvetheconflict or would all the changes be in the shadow shaders?

W

 

 

From: osg-user...@lists.openscenegraph.org [mailto:osg-user...@lists.openscenegraph.org] On Behalf Of Wojciech Lewandowski

Sent: Friday, November 20, 2009 3:58 AM

[Wojciech Lewandowski]

Wyatt,

 

Please read the comment above StandardShadowMap::setShadowTextureCoordIndex method. Tex unit & tex coord indices are changed by search and replace on shader sources. Also see the comments at first lines of StandardShadowMap shaders. Both stages in shaders are initally set to 0/1. But they get replaced when you call setShadowTextureCoordIndex/setBaseTextureCoordIndex methods. Check shaders sources after calling the setShadowTextureCoordIndex/setBaseTextureCoordIndex methods.  

 

If you use your predefined shaders, you probably don't want to do a search and replace on their source. But it won't break anything if you do it, because sought strings would be not found and thus would not get replaced, so nothing in your shader would change. You could be tempted to not call setShadowTextureCoordIndex at all in this case. However, shadow map technique has to know the index at which TexGen for generating tex coords must be set. So you have to call at least sm->setShadowTextureCoordIndex( shadowTexUnit ) to select tex coord index you want to use.

 

On the other hand, if you do not use your own precooked shaders but you take them from StandardShadowMap and apply at the root of the scene, then make sure all search and replace were done before you grabbed the shader. I hope you did not ripped them manually but you do it in the runtime by calling sm->getMainXXXShader/sm->getShadowXXXShader. If you retrieved them first and later called sm->setShadowTextureCoordIndex( shadowTexUnit ), search and replace would be changing unused set of shaders in technique but not these you applied at the root.

 

Finally, I would be careful about using 8 as tex coord index. Even if your OpenGl allows this, I would suspect that some OSG state like TexGen may be limited to 0-7 units. So I would rather use unit 7 instead of 8.

[Wyatt Earp]

Is this what you meant?

Thanks,

W

 

 

 

[Wyatt Earp]

Actually, I copied them from the StandardShadowMap.cpp, put them in .vert/.frag files to be loaded where I load my shaders… Guess that was wrong, huh.

[Wyatt Earp]

Ok… Now I am getting confused.  What are my options on using the shadow shaders in my app?

 

1. If my shaders use 0-6, do I need to call

 

   sm->setBaseTextureCoordIndex( baseTexUnit );

   sm->setBaseTextureUnit( baseTexUnit );

 

to change the base texture unit to something other than 0, since I am using it in my shaders?

 

 

2.  According to the osgShadow programming guide:

 

“What if my objects already have a shader applied to them?

• That shader also needs to implement shadow mapping. See the top of src/osgShadow/ShadowMap.cpp for the basic shader, and use that in your shader (keep the same names for the variables too).

But according to the info below I shouldn’t just manually copy them and use them.  Eventually, what I want to do is incorporate the shader code I need to apply the shadows into my own shaders.  Is this possible?  Or can I simply add a shader to my objects nodes to be applied after my shaders are applied?

 

3.  Not a shadow question, but in what order would shaders be applied if I have a shader on the root node of a scenegraph, and one on a child node?

 

Thx

[Wojciech Lewandowski]

Hi Wyatt,

 

Answer to question 3 first:

> 3.  Not a shadow question, but in what order would shaders be applied if I have a shader on the root node of a scenegraph, and one on a child node?

 

Lets first define what we understand as "shaders". We colloquially use term shaders but we implicitly mean a certain set of shaders complied and linked into a single specific Program. I hope we both agree on this interperetation.

Now lets get to the point: You cannot have more than one osg::Program active while drawing some drawable. Its either this one or that one, not both. Program could be linked from a number of shaders but it has to be one coherent set. Program is treated by OSG like any other state attribute  From many possible programs encounterd during cull traversal only one is used and selected to draw certain drawable. Program selection really works like selection of other state attributes, for example: osg::CullFace. Some NodeA has stateset that sets ProgramA and NodeB - child of NodeA has a state that sets ProgramB , and the last one is used to draw drawables found under NodeB. Clear ? So its impossible to have your shaders and shadow shaders working together. Unless you make them compile and link together into single Program. All documentation assumes some basic knowledge, and do not explain obvious things, when docs and posts say you have to incopoprate or merge your shaders with shadow shaders it means you have to write a  new set of shaders unifing your shaders with shadow.  In other words: you have to add shadow factor computation to your shaders. To do this you have to understand what shadow shaders do first. If you cannot do understand them, then the whole idea may be too advanced for your current skill level.

 

> 1. If my shaders use 0-6, do I need to call 

>  sm->setBaseTextureCoordIndex( baseTexUnit );

>  sm->setBaseTextureUnit( baseTexUnit );

> to change the base texture unit to something other than 0, since I am using it in my shaders?

 

You may skip them. But you must call setShadowTextureCoordIndex and setShadowTextureUnit.  setBaseTextureCoordIndex and setBaseTextureUnit are important if you use default shaders. Default shadow shaders are written for most popular scenario. They assume one base map (diffuse texture) and one shadow map. And fragment shader code applies base texture multiplying it by lighting color modified by shadow factor.  Thats it. Now instead of 1 base stage you apparently have 6 stages. So your shaders are probably much more complex. And your scenario does not belong to most common scenario group. So you have to rewrite your shaders to aditionally compute shadow factor. You have to add 7th stage for shadow map/shadow coords. Go read the shadow shaders, understand them and take these few lines which compute shadow term and integrate into your shaders. Then call sm->setShadowTextureCoordIndex( 7 ), sm->setShadowTextureUnit( 7 ), to make sure LispSM will generate shadow map and shadow coords for your shaders. 

 

> 2.  According to the osgShadow programming guide:

> “What if my objects already have a shader applied to them?

> That shader also needs to implement shadow mapping. See the top of src/osgShadow/ShadowMap.cpp for the basic shader, and use that in your shader (keep the same names for the variables too).

> But according to the info below I shouldn’t just manually copy them and use them.  Eventually, what I want to do is incorporate the shader code I need to apply the shadows into my own shaders.  Is this possible?  Or can I simply add a shader to my objects nodes to be applied after my  shaders are applied?

 

As I said before, you have to rewrite your shaders incorporating shadow term calculation from ShadowShaders. There is no other option for you. You may only use one set of shaders compiled and linked into one Program.

 

Wojtek

 

 PS.  Sorry, if this may be little harsh for you: This whole LispSM is highly advanced stuff. If you want to modify it, you really have to be able to read and understand OSG source code. If last requirement is too much, then consider posting your code asking for help, because it would be much simpler to modify the source, than explain eveything bit by bit.   

[Wyatt Earp]

Ok.. Thanks for the further explanations… I think I understand better now, what I need to do.

 

It isn’t that I don’t want to post code… I am not sure that I am allowed to due to company restrictions.

 

Is “Light Space Perspective Shadow Maps” by Wimmer et. al. Eurographics Symposium on Rendering (2004) what OSG LispSM is based on?

 

Perhaps using ShadowTexture might be more in line with my skills since it does not use a shader?

[Wojciech Lewandowski]

Hi Wyatt,

 

> Is “Light Space Perspective Shadow Maps” by Wimmer et. al. Eurographics Symposium on Rendering (2004) what OSG LispSM is based on?

Yes. However, LispSM algorithm differes from traditional shadow maping only by a method of computing shadow map projection. So all the wiring (uniforms, state attributes, textures) is the same as for StandardShadowMap. Only contents of shadow map projection and texgen matrices differ. 

 

>Perhaps using ShadowTexture might be more in line with my skills since it does not use a shader?

It really depends on what you are trying to accomplish. The outdoor example pictures you posted do look like your app is a right candidate for LispSM.

 

Wojtek