Strange. Sounds like our platforms are behaving a bit differently. If you get rid of almost all the artifacts, you can try adjusting the line that calls DirectionalParallelSplitShadowMaps::setMapsRenderedPerFrame(). This gives you a performance/quality tradeoff and the demo currently has it set for higher performance. Try setting it to NUM_SHADOW_MAPS and see if your remaining artifacts go away.
When you don't render every shadow map each frame, you can usually move around without seeing artifacts, but if you start to move too fast they appear occasionally. - Terry > > Hi Terry, > > > Anyway, I tried your changes; my comments are below.... > > I've attached some screenshots so you know I'm not just making this > up... :-) Unfortunately I don't have any other machines to test this > on... > > >> * It seems that the program doesn't like to have text displayed (the > >> whole scene turns black - perhaps an overlap in texture units?) > > > > I don't see this problem. I pressed "s" to turn on statistics and > > everything still looks alright. Running on Suse 10.2 linux with an > > 8800GTX. > > Strange, it happens to me if I either press 's' or 'h'. So I guess > this is probably down to something here (Windows itself, nVidia > Windows driver, different video card, whatever). I'll try to test a > bit more when I have some time. > > See PSSM-after_stats.png > > >> * Some strange ghost shadow artifacts appear when you change > >> threading models > > > > I don't see this problem either. I pressed "m" to change threading > > models and everything still looks alright. > > Again, probably down to something different about our configs. I don't > know much about the technique itself, so it's hard for me to know > what's going on. > > See PSSM-after_threading_model_change.png > > >> * The shadows move around and have line artifacts in them if the > >> camera moves, but they look fine when the camera stops moving, so I > >> guess the shadows' view matrix is not updated every time it changes? > > > > pssm->update() is being called too late so matrix changes are lagging > > by a frame. If you use the original updateSun() call instead of the > > new update callback, this problem goes away. Works for me under all > > threading models. I don't know enough about osgViewer yet to know how > > to make this update callback work. > > Sorry about that, adding the update callback was a test I did to see > what would fix the next problem (threading causing artifacts). Setting > the data variance was enough, so I should have removed it... You're > right, putting the updateSun() back in the frame loop where it was > originally makes the shadow stay in the right place, though I still > see some artifacts... > > See PSSM-moving_camera.png > > >> I set the sceneSS to DYNAMIC data variance and made the updateSun() > >> run in an update callback because otherwise the shadows would have > >> some line artifacts unless the viewer was run SingleThreaded. > > > > I don't see anything like this either. > > If I remove the update callback AND I comment out the setDataVariance > line, I see some artifacts like in PSSM-moving_camera.png . Unless I > start the program with --SingleThreaded. (the default threading mode > is DrawThreadPerContext on my machine - what's yours?) > > As I said, I was just curious as to how this ran, I don't really have > much time to debug it myself, and since you don't have the problems I > report (so can't really debug them either), there isn't much we can > do. We'll see what the future brings... > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [EMAIL PROTECTED] > http://whitestar02.webhop.org/ > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
