[osg-users] Methods to improve large scene shadows with ViewDependentShadowMap

[Wang Rui]

Hi all,

I'm currently working on an example that uses osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large area of buildings. It can work correctly on a huge city which is created by CityEngine and then converted to OSG styled scene graph. It also generates aliasing issues as expected, but I'm still looking for some good solutions to reduce such problem and want to discuss them in this thread if possible. My test program and a simple shader file can be found in attachement.

I've already read a similar topic at:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html
And I believe it is necessary to apply some filters on the shadow map (the test shader file simply uses PCF here) and increase the texture resolution as well. But for huge scene, a 4096-sized RTT texture will be a heavy burden. So I wonder if there are some more methods to choose, for example, is it possible to change the internal format of the texture to GL_DEPTH_COMPONENT32 to improve the shadow comparision process?

Meanwhile, is it necessary to perform a screen space blurring to reduce the aliasing effect? It is a serious problem for my scene now as I can't use a very high resolution. Could anyone suggest some other possible methods on the post-processing level? To be honest, the ViewDependentShadowMap is the best shadow solution for me at present as it is easy to be integrated with custom shaders and embedded into a deferred shading framework.

The test city models are about 180MB. If any of you think it important for digging into the problem. I'd like to share them freely, too, as I believe these automatically generated models should not have any copyrights with them. :-)

Cheers,

Wang Rui

[Luc Frauciel]

Hi Wang Rui,

I'm also working on very large urban areas with  osgShadow::ViewDependentShadowMap.
I encounter the same problems.
I also had to use some kind of PCF to reduce some inacceptable noise (huge 'Moiré' effects).
I tried to use PSSM recently introduced in ViewDependentShadowMapto cope with aliasing effects with no success :
- PSSM procuce some strange artifacts on half of the view when mixing the two shadow textures (each half shadow  is ok)
- the separation line is not adapted to a 'human walking' point of view (too far in the scene)

I doubt that changing the depth of the shadow map will produce noticable effects : numerical instabilities will exist, whatever the depth.

At what angles did you encounter innacceptable alisasing issues ?
For views that are not near tangent to the ground plane, the results I got seems ok.
Is your problem global or limited to certain points of view ?
Is your target resolution way beyond the resolution of the shadow map (10000*10000) per ex ?

       Luc

De :	Wang Rui <wang...@gmail.com>
A :	OpenSceneGraph Users <osg-...@lists.openscenegraph.org>
Date:	12/03/2012 10:39
Objet :	[osg-users] Methods to improve large scene shadows with        ViewDependentShadowMap
Envoyé par :	osg-user...@lists.openscenegraph.org

---

[pièce jointe "screen_space_shadow.cpp" supprimée par Luc Frauciel/STAR-APIC] [pièce jointe "shadowRenderer.frag" supprimée par Luc Frauciel/STAR-APIC] _______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi Rui,

Artifacts can be caused by a number of different reasons, as I have
seen the models, screenshots of the artefacts I don't feel comfortable
pointing at any particular cause or solution.

Having a public model we can test against would be very useful. Also
modifying the osgshadow example to have a unit test for these case
would also be useful. Given a unit test we as group can start
refining things for the problem cases.

As a more general note ViewDependentShadowMap doesn't yet provide
shaders that resolve the issue correct lighting of shadows, the thread
you link to discusses this topic. Introducing the required shaders as
an option into ViewDependentShadowMap would address one of the areas
that artefacts can be seen when users don't provide their own shaders
that do the lighting correctly. This won't solve all the potential
artefacts that we see when doing shadow mapping but it would at least
discount one possible set of problems.

Robert.

[Wang Rui]

Hi Robert,

I'd like to provide a set of city models for shadow tests. It is already constructed with paged LODs so can be viewed smoothly on my Windows 7 and GTX 460. I've uploaded it at box.com, totally two compressed packages:

http://www.box.com/s/s1bnf4eqenrc30opxzj4

http://www.box.com/s/ubu4186593fjc8tslntq

Of course tarballs are not suitable for public test. It should be comfortable if we could load and render the city from an HTTP address, just like the earth_bayarea example dataset. The snapshot attached shows that most of the shadows are at the right place but some with obvious aliasing issues and streaks (as on the right bottom side).

Cheers,

Wang Rui

2012/3/12 Robert Osfield <robert....@gmail.com>

[Wang Rui]

Hi Luc,

I'm glad that someone is working on the same topic and we can share opinions and experience all the time. :-)

2012/3/12 Luc Frauciel <luc.fr...@star-apic.com>

At what angles did you encounter innacceptable alisasing issues ?

A snapshot of the shadowed city I'm working with is attached in my last post, so does the download link of the model files. It shows some distinct jags and streaks on a few building surfaces.

 

For views that are not near tangent to the ground plane, the results I got seems ok.
Is your problem global or limited to certain points of view ?

I think it may happen in any position. But a view from the high altitude is always better.

 

Is your target resolution way beyond the resolution of the shadow map (10000*10000) per ex ?

The target city's radius is about 2800 and it is formed up by about 1000 mansions.

Wang Rui

 

[Robert Osfield]

HI Rui,

Thanks for the links to the data, I will download and have a
experiment later, most likely tomorrow as I have to go out quite soon.

The screenshot is suggests to me that the main artefact is simply that
the shader used/fixed function pipeline isn't computing the shadowed
colour correctly and would disappear if appropriate shaders were used
to make sure the back facing triangles are coloured the same as the
shadowed region. When using the standard fixed function pipeline you
just get black for the shadowed around so the result always has this
artefact.

Robert.

[Wang Rui]

Hi Robert,

I've made some tests today and gradually know my problems, but feels thorny to solve them. :-)

The shadowed scene looks good when it is displayed separately. Although there are still aliasing when tilting the view point to have a horizontally view, I think one of the cause is the precision from the near to the far plane, and can bear or resolve it with some blurring methods. But when I place the city on the earth and try to make shadows on it (the earth tiles are not included as shadow casters or receivers), there is one major problem: the shadow may disappear suddenly when I'm adjusting the look-at vector for horizontally views. This issue always occurs when I'm in the opposite direction of the light. I tried following the code in ViewDependentShadowMap and guess it is still related to the near/far computation, as in my scene graph, the far plane value may be extremely large because of the earth radius.

I don't have a proper solution for that case but wonder if we could have a callback/option in ViewDependentShadowMap to enable setting user-defined projection matrices instead of reading them from the cull visitor, with which we can set up the light frustum to have a fixed near/far pair instead of a changing one. As shadows are meaningless when they are far away from the viewer, I think this is suitable for most cases and can help improve the shadow quality when handling large scene cases. The theory of PSSM and CSM algorithm may help, but at present I think they are not implemented in the ViewDependentShadowMap class (yes, we have the PSSM but it has problems working with RTT cameras at present :-)

[Wang Rui]

Hi Robert,

Some comments on my last post. It may not be a projection matrix problem... I've found that in the ViewDependentShadowMap.cpp file, implementation of class ComputeLightSpaceBounds:

    void update(const osg::Vec3& v)

    {

        if (v.z()<0.0f)

        {

            //OSG_NOTICE<<"discarding("<<v<<")"<<std::endl;

            return;

        }

        ...

    }

Should it be "v.z()<-1.0" here as the clipping space coordinates are in the range of [-1, 1]? I changed this line and it works for me; otherwise the city on earth will be splitted in a strange way as shown in the attached snapshot.

But I'm still struggling with another serious problem that the whole shadow map may disappear suddenly when I'm looking with a horizontally view from the opposite direction of the light vector. I checked the code and surprisingly found that the ComputeLightSpaceBounds returns an invalid bounding box in such case. That means the entire scene may be culled as in the light space frustum? I'm just confused now but will go on tomorrow.

Any good ideas about that? :-)

Wang Rui

2012/3/13 Wang Rui <wang...@gmail.com>

[Wang Rui]

I finally find the reason of my second issue (the shadow disappears some time, because of the view matrix computation from the light) and already submit a patch for both problems. Now I'd like to try to work out a more comfortable shader solution for this great shadow technique and see if it could make the life better. :-)

Wang Rui

2012/3/14 Wang Rui <wang...@gmail.com>

Hi Robert,

[Robert Osfield]

Hi Rui,

Sorry about not being quicker to respond, I've been juggling other
tasks. I'm about to dive in a review your changes, ideally it would
be good to have the dataset and animation path that reproduces the
problems, is there any chance that you could post this online?

Thanks,
Robert.