http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_project/
*Question: In which directions, we can further improve PSSMs? * *Answer:* PSSM+VSM <http://forum.beyond3d.com/showthread.php?p=975976> (variance shadow maps <http://www.punkuser.net/vsm/>) and PSSM/CSM+LiSPSM (light space perspective shadow maps) might be better ways to further improve PSSMs. A good example for PSSM/CSM+LiSPSM is the professional game Lost Planet<http://www.lostplanet-thegame.com/flash_index.php>, refer to the discussion here<http://forum.beyond3d.com/showpost.php?p=919807&postcount=116>for more information (just use Ctrl+F to find "Fan Zhang" on the page). For your convenience, I post the PSSM/CSM related part in the discussion below, * * <http://www.watch.impress.co.jp/game/docs/20070131/3dlp91.htm> <http://www.watch.impress.co.jp/game/docs/20070131/3dlp92.htm> * Glitch in LiSPSM <http://www.watch.impress.co.jp/game/docs/20070131/3dlp91.htm>* * Cascade-extended LiSPSM <http://www.watch.impress.co.jp/game/docs/20070131/3dlp92.htm>* Furthermore, since the shadow-map alignment depends on the light-view configuration, the shadow boundaries might "flicker" as the viewer moves. See a movie here (.avi)<http://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/flickering.avi>to show this problem. For this problem, when using a shadow map size over 1024 and the number of splits is greater than 3, this phenomena can be nearly eliminated with PCF/VSM. Another possible solution is used in Terry Welsh's OpenSceneGraph-based implementation<http://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/PSSMdemo_OSG_Terry.tar.gz>, which moves the light projection in *x* and *y* coordinates in a texel size, so you are always having the same aliasing pattern. However, when you change the size of the projection (i.e. the *min* and *max* vectors in the *crop*matrix in Oskari Nyman's DirectX9 implementation<http://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/PSSMdemo_DX9.zip>), this problem still happens. Anyway, as I mentioned, this issue is not noticeable at all if we use PSSM+PCF/VSM. The last issue might the performance. I've to say, as the tremendous advances in modern GPUs, even without hardware-acceleration, PSSMs could achieve a high fps in practical applications. In our Gems 3 paper/implementation, we proposed the acceleration methods on DX9-level and DX10-level GPUs. Please check this page back later. In summary, personally, I don't think the performance is a problem for PSSMs on modern GPUs. * Alors, OSG take same way? who could support me ? regards * 2008/5/27 Wojciech Lewandowski <[EMAIL PROTECTED]>: > Hi J-S, > > Yes it is view dependent. Have you seen some issues with pure >>> osgShadow::ShadowMap in multi view configurations ? >>> >> >> Not at all, I was just curious since you said StandardShadowMap is >> equivalent to osgShadow::ShadowMap - but the former is view-dependent where >> the latter is not. >> > > I thought about it for a while when I was struggling with multi view / > multi threaded OSG on XP. Threre exists some remote possibility for > osgShadow::ShadowMap to fail in threaded modes. Just an example: multicore > default DrawThreadPerContext uses two SceneViews in parallel. While first > does draw for previous frame, second does cull for next frame. Teoretically > second SceneView may invoke ShadowMap::cull which could alter shadow TexGen > matrices before first SceneView managed to use it for generating shadow tex > coords. This would produce shadow texture misalignment and possible flicker > between scenes. But in practice I doubt anyone would be able to notice it. > > You may try to add setMinLightMargin( 10 ); in osgshadow paragraph >>> where --lispsm technique is created. There is a catch though. You may be >>> hit >>> by some assertion code I added today. If you want to try this please >>> update >>> ConvexHull.h header (attached here). >>> >> >> Yep, that solves it. Interesting, so there's a few more parameters to >> tweak depending on the scene. >> > > These techniques have some limitations and may not be interesting for > eveyone. Techniques were created for vis simulation scenarios where > databases are usually larger than view frustum (considering their bounds) > and implicitly assume that all objects can cast shadows on themselves. So I > assume that shadow casting and shadow receiving scenes are basically the > same. I think that other MinimalXXShadowMap could be created to take > advantage of the situation where shadow casting and shadow receiving scenes > differ. LisPSM would not require changes. All what would be needed is to > derive it from this new base class. > > Cheers, > Wojtek > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ******************************************** Adrian Egli
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
