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 2012/3/12 Robert Osfield <robert.osfi...@gmail.com> > 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. > > On 12 March 2012 13:20, Wang Rui <wangra...@gmail.com> wrote: > > 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.osfi...@gmail.com> > >> > >> 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. > >> > >> On 12 March 2012 09:38, Wang Rui <wangra...@gmail.com> wrote: > >> > 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 > >> > > >> > > >> > _______________________________________________ > >> > osg-users mailing list > >> > osg-users@lists.openscenegraph.org > >> > > >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> _______________________________________________ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
