improved shadowmapping

just a hint about improving shadowmapping quality maybe some here havent heard about
based on a post on gamedev.net
http://www.gamedev.net/community/forums/topic.asp?topic_id=405955
which got me thinking, yeah who saiz u need to draw the shadowscaster + reciever geometry in the correct position, better to apply a nudge to geometry closer to the camera.
its still early days, but this technique does look promising

both screenshots have the same size SM + frustum, one standard + one with distorted vertices

What specifically are you doing? Could you give some more details?

Superficially it looks similar to perspective shadow maps.

[http://www-sop.inria.fr/reves/publications/data/2002/SD02/?LANG=gb](http://www-sop.inria.fr/reves/publications/data/2002/SD02/?LANG=gb)    

[http://download.nvidia.com/developer/GPU_Gems/Sample_Chapters/PSMs_Care_and_Feeding.pdf](http://download.nvidia.com/developer/GPU_Gems/Sample_Chapters/PSMs_Care_and_Feeding.pdf)    

If it’s not the same what are the key differences?

EDIT: never mind, I see the gamedev link has some details I’ll look at that. I’ll leave these links here though.

Welcome back, Dorbie :slight_smile:

Originally posted by zed:
just a hint about improving shadowmapping quality maybe some here havent heard about
based on a post on gamedev.net

I’m very anxious to hear more details!
What warping function do you apply (a 2d function like suggested in the thread)?
Obviously 2d warping introduces z interpolation errors - how bad are they?
I replied on gamedev.net that the “robust” alternative was indeed not robust in the sense that vertices inside the view frustum could be warped outside the view frustum - did you solve that?

well my method is a true zed method, as in i didnt understand the original one, log? thats something u throw on the fire whilst rustling up some bacon + beans right.
my method

  • based on dist from camera (viewer camera) to vertex
    i add an offset along this vector based on the dist
    ( i havent checked it thoroughly?)
    but there is a distortion of shadows when objs become close to the camera (see the above pic notice the cloest shadow is pushed back a bit, but the pink guy behinds shadow is in the right place cause the errors resolve quickly, dist^2)

alternative was indeed not robust in the sense that vertices inside the view frustum could be warped outside the view frustum
sorry im a bit slow, which view frustum, the cameras or the lights/shadows?
i suppose it doesnt matter, from my looking it depends on the ‘tweaks’ involved.
ie u can make it so evrything (including stuff outside the (normal) frustum is captured, at the expense of lesser near detail quality ( but still have better than normal orthoSM detail )

sorry mate my main focus graphically is HDR (specifically logluv32 hybrid), not to mention i wanna make a proper skinned character + not mr blocky (whose boxs dont even line up!!!, ****e hired help nowadays).
il try to post a couple of screenshots tomorrow showing thats its a 99% win situation

oh yes welcome back dorbie, the number1 (+ up there smartest) poster, though our vulcan friend will push u close this year, such potentual at such a young age , i dont know, kids
(yes it is similar to PSM as in u wanna empasize the close stuff but the implentation is diferent)

not to mention i wanna make a proper skinned character + not mr blocky (whose boxs dont even line up!!!, ****e hired help nowadays)
Well, you wanted character animation but you got marching cubes implementation instead :smiley:

I’m planning to implement PSM sometime soon, so I believe your post will be usefull to me. My bet will probably be on PSM’s since they allready have some additional articles published that further improve their quality and neutralize artifacts and I believe we can expect some other improvements proposed someday.
No matter what approach I’ll use, but your post will certainly get me more motivated :wink: , so thanks!

hmm had a bit of a play around this time drawing the borders of the SM with CLASP_TO_BORDER


as u can see its not the same area ( i thought it was ) then again this is first time showing borders (im pretty sure it was before even much better, just gotta tweak the figures now i see the borders.
ya know, hi - five

Well, you wanted character animation but you got marching cubes implementation instead
ha, very good (then again theyre not really cubes more distorted box freaks, those that are not fit to be cubess).
ultimatly this is the crap that bothers me, the thing is i have to have a proper character there marching, (which is gonna cost hours of manhours cause my graphics guy is me) otherwise i can implement best SM, HDR whatever but still the punters are gonna say (but theyre boxes!!!)

Originally posted by zed:
[b] well my method is a true zed method, as in i didnt understand the original one, log? thats something u throw on the fire whilst rustling up some bacon + beans right.
my method

  • based on dist from camera (viewer camera) to vertex
    i add an offset along this vector based on the dist [/b]
    It’s been a while since i read the gamedev.net article, but from the sound of it you perform the distortion in 3D space before the shadow map projection, while the original was projecting the camera position into shadow map space and deforming the UVs.

Yours sound a lot more simple to implement (that’s just a couple instructions in the vertex shader, right ?) while the original is a bit more complex, although still more simple than all perspective shadow maps techniques.

The main restriction to this technique is that it’s tesselation dependant, since the deformation should in theory make the triangle lines become arcs, and they remain lines, meaning that for very large triangles, you get an incorrect projection.

I tested LSSM (the improved one, that was published in ShaderX4 i think), and came to the conclusion that, although in average it’s a huuuge improvement compared to standard shadow maps, its worst case is also a lot worse than standard shadow maps, and make it unusable in a “normal” program. It can be seen in the official demo if you orient the camera in a very specific direction compared to the light direction (around 180°).

Another problem with all those perspective shadow maps techniques is that they rely on the bounding box of the scene. When your scene is huge and want shadow maps to cover tens of kilometers (up to the horizon), they simply don’t work that well. I’m still trying to find a good technique that’d work at distances up to 50 Km.

Y.

i tried large triangles and they seemed ok
there are distortion problems though if the light source is low down + the camera is facing downwards.
so for a flight simulation etc its prolly not the best idea, but for a FPS it seems pretty good,
also from the looks of it, it doesnt suffer the same problems as PSM/lispSM etc where the near shadows look good, the far away ones suffer

Originally posted by Ysaneya:

Another problem with all those perspective shadow maps techniques is that they rely on the bounding box of the scene. When your scene is huge and want shadow maps to cover tens of kilometers (up to the horizon), they simply don’t work that well. I’m still trying to find a good technique that’d work at distances up to 50 Km.

Did you tried the cascading shadow maps?

Yeah, i’m currently working on my CSM implementation.

It’s not as good as i was expecting. I’m currently using 4 shadow maps, but that’s not enough to get a good quality both on near objects (50m) and far away ones (20 km). To hide the transition between the shadow maps, the best is to increase the range by 2 every time. Starting at 50m, 4 shadow maps would reach 50->100->200->400m. So 4 are not enough. With 8 you’d get 6400m, and by playing with the increase factor, you’d get an ok quality at 20km. But that’s 8 shadow maps to render your scene into.

One of my main interest with cascaded shadow maps was the ability to cache the results, ie. to not recalculate the largest shadow maps every frame, but every N frames. That doesn’t work very well either, as soon as you have moving/rotating objects in the distance, the dirty shadow map no longer matches the geometry, and you get shadowing z-fighting… it looks horrible.

Maybe an hybrid solution (LSSM + CSM, ie. 2 levels of CSMs, each calculated with LSSM) might work…

Y.

anyone got any working glsl examples of lssm
cause i wanna see how my method compares to them, quickly

theres one here
http://www.cg.tuwien.ac.at/research/vr/lispsm/
but i get the error

OpenGL 2 supported.
error: can’t compile Fragment Shader:depthOnly.frag
(6) : error C0000: syntax error, unexpected $undefined at token “<undefined>”
(6) : error C0501: type name expected at token “<undefined>”

error: can’t compile Fragment Shader:sky.frag
(13) : error C0000: syntax error, unexpected $undefined at token “<undefined>”
(13) : error C0501: type name expected at token “<undefined>”

error: can’t compile Fragment Shader:shadowNdiffuse.frag
(86) : error C0000: syntax error, unexpected $undefined at token “<undefined>”
(86) : error C0501: type name expected at token “<undefined>”

Can’t create shader objects. Exiting now.

theres also an older working example there but doesnt use glsl, thus will require a bit of work to change over

ta zed

Originally posted by Ysaneya:

It’s not as good as i was expecting. I’m currently using 4 shadow maps, but that’s not enough to get a good quality both on near objects (50m) and far away ones (20 km).

One approach you might consider for such huge range is to to use the shadowmaps for only part of that range (e.g. 1km) and at end of the range fade to precomputed intensities stored within the vertices (so big static objects still cast some shadows). I think that something similar is used by the Fable game where I did not notice this until I started to looking for cause of somewhat lighter area around my avatar.