glsl shadowmapping

[ninogenio]

hey guys,
ive spent the past week studying and working on omni direction cube shadow mapping.. im very close too a working example but for some reason i cannot get my shadow too project correctly over the scene.

i've checked and debugged.. and i am correctly grabbing 6 depth textures from the position of the light source in up down forward back left and right on a basic shader then pass everything correctly too the shadow shader. im 99% sure its something silly ive done in my shaders. probably while converting light_positions too camera space or something..

i've tried loads of things but alas nothing works.

i can provide full source if needed.

if anyone can help it would be massively appreciated id love too get this working.

[ninogenio]

i think i have this really close now,

all my shadows have an offset though, im sure im transforming my light position into the wrong coordinate system but just cannot for the life of me see where. this exe shows nice big shadows being projected unfortunatly with offsets.

[ninogenio]

hey again guys,

i finally managed too get this working!!!! a week later and loads of mind bending bugs. i am quite happy with it, ill fine tune it and add textures back in now.

in the end it came down too lots of little hidden things i had done wrong just kept debugging and tuning and it all came together.

[Rbz]

Nice work Nino.
It works fine on nvidia 8800 and breaks on intel 3000 hd.

[ninogenio]

cheers rbz,

hmm thats strange, your intel hd3000 is dx10 compliant so it should work. i read in a few places though that support for glsl ver 330 is buggy on it. however having said that there is a 90% chance my code is at fault somewhere. i may be enabling a gl state change somewhere and not disabling it after.

ill try and see if one of my friends might have a hd3000 in there hardware so i can see where it falls over. cheers mate.

edit- just realized ive got a secondary chip in this laptop lol its a hd4000. it runs here but the shadowsample seems too mess up big time. looks like texture cube sample results get scewed.. ive got a little more work too do. i would like too know also if anyone has an ati gfx card dx10 capable if it runs ok there. so far ive only had this tested on nvidia side.

edit2- right ive fixed this too the point that it works on both my gt650 and my internal hd4000 i had too get rid of the extension call and also lookup the cube texture with a normal texture call in the fragment shader. also my standerd intel drivers had a known bug where cube maps didnt work correctly so had too update my drivers.. hopefully this works on the hd3000 too..

cheers.

[Rbz]

Works fine now!

Really, I don't expect things to work on this intel board, it's mainly for browsing internet / watch videos etc, but it is always nice to make your software more compatible as possible.

[hellfire]

Does some fancy moires on my Nvidia GTS 450 (probably lacks some thresholding) and crashes on ATI X700 (maybe some missing extension).
In this situation (few omni-directional lights, low scene complexity & perfectly sharp shadow edges = the doom3 scenario) you're probably better off with shadow volumes.
Shadow maps are great for spot lights (so you just need a single render pass with lots of light-frustum culling) and soft shadow edges.

[ninogenio]

cheers guys,

@rbz.thats awsome too know and yeah totally agree mate, the more compatable the better. its win win for me now as i realize i have two chips too debug with.

@helfire,

nice sugestions. the moire patterns that can be seen is definitly thresh hold related and also coming from the fact each segment is a box with the inside faces squished into the same space, which is not ideal. im trying too fine tune it atm. if the camera is moved near the shadow casting object there is also a bit of pixel skipping and near clipping precision issues that can be noticed.

stencil shadow volumes look exciting also, there next on my too do list. ideally ill be able too easily switch between both types of shadowing in my engine. so eventually shadows should be pretty much taken care of and i can easily choose which works best for a particular scene.

also i dont think this will work with dx9 class hardware such as the x700 as i use ver330 in my shaders. it could be as simple as changing the version define in the shader files too a lower number that still supports in/out as opposed too varying, as this doesnt really do any exotic stuff that requires the higher version number yet.

[ninogenio]

the shadow acne in this is driving me nuts  ,

ive added a stack of old car tires into my scene which produces a cool shadow, but when self shadowing they produce terrible acne. i have tried tons of stuff with the latest fail being..

Code: [Select]

        vec4 abs_position = abs(position_ls);
  float fs_z = -max(abs_position.x, max(abs_position.y, abs_position.z));
  vec4 clip = lightprojmatrix * vec4(0.0, 0.0, fs_z, 1.0);
  float depth = (clip.z / clip.w) * 0.5 + 0.5;

  float result = texture(shadow, vec4(position_ls.xyz, depth),+0.005);
float visibility = (result * result);
if (visibility>dot(position_ls.xyz, position_ls.xyz))
{
visibility = dot(position_ls.xyz, position_ls.xyz);
}
with the visibility variable used on the fragment color at the end stage..

everything ive tried thus far seems too make it worse. using shadow cube maps makes it a little more difficult, i was wondering if you guys have ever cured such a problem and what methods you used too work around it.

ohh and i do the usual front face cull for the shadow map generation.. then switch too back face culling for the final render. other wise the amount of acne is crazy.

[ninogenio]

and just too show what im up against here is a little example,

the problem only arises when you move the camera too the tyres back faces. when i say back faces i mean from the lights pov. as long as you stay looking at front faces from light pov everything is correct.. it its really the shadow rays coming through the object towards the camera that bleeds through.

[hellfire]

What exactly do you store in your shadow map?
If it contains depth values you can't compare them to the euclidian distance.

[ninogenio]

cheers mate,

yeah i did quite a bit of reading yesterday, it seems like shadow maps are really a minefield where things like acne and peter panning are concerned with many different approaches too fixing..

the shadow map is made up of six clamp_to_r depth buffer captures.. i kind of found a fix yesterday with.

Code: [Select]

float result = texture(shadow, vec4(position_ls.xyz, depth));
depth = depth*(result*result);
    float visibility = depth > 0.0 ? 1.0 : 0.0;

but this was really hacking around.. it got rid of 90% of acne but is not ideal in that it gives either 0 or 1 as a result which leads too hard edge shadows. and the results are at there best when checking against depth > 0.0 with anything higher leading too more acne, meaning that its not possible too get rid of that last little bit..

i was reading that when storing the depth values for precision sake, as really close together polygons can be confused as being on the same depths its a good idea too offset the polygons in there normals direction by a little does this sound like a reasonable next step..

[hellfire]

Have you realized that the value which is stored in the depth buffer is *not* the fragment's distance (in xyz euclidian space) to the camera but just the projected (and quantized!) z value ?

[ninogenio]

ahhh yes of course..

ive been messing around with so many different concepts over the past few days i had gotten mixed up.. so really too add an offset its as simple as.

Code: [Select]

        float bias = 0.039;
  float depth = ((clip.z-bias) / clip.w) * 0.5 + 0.5;
        float result = (texture(shadow, vec4(position_ls.xyz,depth)));

    float visibility = result;

this pretty much cures all the moire but obviously introduces peter panning the more bias == more panning, but i **think** i can cure that with fiddling with my geometry.

i never thought good z based shadows were as difficult too get right..