i have implemented shadow maps. but unfortunetaly some wired artefacts appear at the shadow border.
i’m already using glPolygonOffset but the problem won’t dissappear.
here is a screenshot of the problem.
maybe some of you have any suggestions. any help is kindly appreciated!
Unfortunately, there is no simple way of getting rid of these artifacts in shadow maps. One solution is to render back faces (from the light POV) during the shadow map generation pass. Because backfaces are, by default, shaded dark during the lighting pass (since they are facing away from the light) therefore the artifacts will be hardly noticable.
Maybe, try to change projection matrix light view in order to shadow source was at full window. (you can to use gluPerspective ())
These shadow maps will always have artifacts like this because most of the problem is caused by polygon subdivision, you could alter the geometric subdivision to help some, and you could help a bit using offset to fix any artifacts due to zbuffer precision, the best solution for this geometry though is to only modulate the direct lighting contribution. This means that for diffuse L.N (or whatever you use) the lighting result will tend to zero near the shadow silhouette. Then you can add ambient & other terms.
So this artefacts are “ok” and not a coding error.
rendering back faces only is not possible because i will have to deal with open meshes. that was one of my reasons to choose shadow maps and not shadow volumes.
@racoon: i have tried this now, but it effects the result only slightly.
@dorbie: do you suggest using some sort of shader for lighting?
a idea which came just to my mind:
would it help if i would alter the vertices slightly in direction of the normal and use this modified geometry for generating the shadow map?
Had you taken everything out the depth texture resolution limit? Not grudge!
this is was i have done:
set the near plane right before the shadow source
set the far plane right after the shadow source
set the fov so that the shadow source fills the whole shadow map.
set the perspective with gluPerspective
is there anything i have missed?
I have this paper that shows how you can make two depth maps, one for front facing and one for backfacing triangles, then contruct a new depth map which contain the depth values between the first two and use this as your shadow map. This requires twice the renderings but gets rid of the problems with shadow acne and biasing issues. Last year John Carmack talked about doing this and how it works great. I’ve been meaning to try it but havn’t gotten around to it yet.
that sounds good. Do you have a link where this paper can be found or the name of the paper, so i can google for it?
as speed is not so much of an issue this could solve my problem
- is there anything i have missed?
- this is right.
But as far as know the shadow is must be ideal for this geometry and depth tex. resolution 512x512 (and higher).
Yeah that’s it. I’m not at home so I couldn’t go look what the name of the paper was and I couldn’t remember it at all. I meant to go searching for it but I got carried away with something. Glad to see someone found it though.
Something like this?
glCullFace( GL_BACK );
glCullFace( GL_FRONT );
i think that works fine with closed geometry. but with open objects errors can occur, IMO. assume this case:
Eye-> | | \
the first object would only appear in one of the two maps.
Models with holes will always cause probems in more areas than just shadow mapping. You should have closed models anyway.
I implemented this dual depth pass and used the stencil buffer to consider only averaging when there are front and back faces. Basically, i render back faces in the first pass with increasing the stencil buffer. And in the second pass, i render front faces, considering pixels only where there were back faces (using stencil test). But in such case, only front faces won’t cast shadows so your open objects could be a problem.
May be there is some solution using stencil buffer in a similar way. For example (just an idea), render front faces and increase stencil in first pass and in second pass, render back faces and average depth when stencil test passes. This doesn’t work correctly, there is a problem with the depth test since you render front faces first, but maybe it is a way to investigate.
That’s an interesting idea of using the stencil buffer for trying to correct depth maps with an open model. I’ll have to think about this some more.