[osg-users] ShadowMap problem...

Wyatt Earp wyattbsearp1881 at gmail.com
Sun Nov 22 15:58:42 PST 2009


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?

 

W

 

 

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Wojciech
Lewandowski
Sent: Sunday, November 22, 2009 5:21 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] ShadowMap problem...

 

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
<http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src
/osgShadow/ShadowMap.cpp> 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.   

 

 

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Wojciech
Lewandowski
Sent: Friday, November 20, 2009 5:47 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] ShadowMap problem...

 

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.

 

Cheers,

Wojtek Lewandowski

  

 

From: Wyatt <mailto:wyattbsearp1881 at gmail.com>  Earp 

Sent: Friday, November 20, 2009 10:15 PM

To: 'OpenSceneGraph Users' <mailto:osg-users at lists.openscenegraph.org>  

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

 

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-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Wojciech
Lewandowski
Sent: Friday, November 20, 2009 3:58 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] ShadowMap problem...

 

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 <mailto:wyattbsearp1881 at gmail.com>  

To: 'OpenSceneGraph Users' <mailto:osg-users at lists.openscenegraph.org>  

Cc: 'Wojciech <mailto:lewandowski at ai.com.pl>  Lewandowski' 

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

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

 

Is this what you meant?

Thanks,

W

 

 

 

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Wojciech
Lewandowski
Sent: Thursday, November 19, 2009 4:56 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] ShadowMap problem...

 

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

 

 

 

From: Wyatt <mailto:wyattbsearp1881 at gmail.com>  Earp 

Sent: Thursday, November 19, 2009 10:45 PM

To: 'OpenSceneGraph <mailto:osg-users at lists.openscenegraph.org>  Users' 

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

 

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.

 

cid:image001.png at 01CA692E.7A38B7F0

 

cid:image002.png at 01CA692E.7A38B7F0

 

 

cid:image003.png at 01CA692E.7A38B7F0

 

W

 

 

 

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

> From: osg-users-bounces at lists.openscenegraph.org [mailto:osg-users-

> bounces at 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,

> 

> > 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,

> 

> J-S

> --

> ______________________________________________________

> Jean-Sebastien Guay    jean-sebastien.guay at cm-labs.com

>                                 http://www.cm-labs.com/

>                          http://whitestar02.webhop.org/

> _______________________________________________

> osg-users mailing list

> osg-users at lists.openscenegraph.org

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

> openscenegraph.org


  _____  


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

  _____  

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

  _____  

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091122/79e98404/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 8710 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091122/79e98404/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 8367 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091122/79e98404/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 7579 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091122/79e98404/attachment-0002.jpeg>


More information about the osg-users mailing list