shadow map depths

[titan]

I can't get rid of the artefacts on my models no matter how much I try. I'm using a the bounding sphere to create a view frustum that is very minimal to take full advantage of the depth range and I'm using a 24bit depth buffer with a 1024x1024 pbuffer.

I tried rendering with front face culling instead of back face culling, but I still had artefacts, just on the back of the model instead of the front.

Does anybody have any suggestions as to what I could try to completely remove the artefacts?

My first thought was that if just rendering the front facing polys gave errors on the front and rendering back facing polys gave errors on the back what I need to do is average them. With a closed model this will get a value in the centre of the object. It'll be slower because you render twice and then average, but that's ok if it is the only way to get rid of the artefacts. Is this a good idea?

I am working on that right now, but I'm stuck. I can't seem to get get glDrawPixels(w,h,GL_DEPTH_COMPONENT,GL_FLOAT,data) ; to work when I have switched to the pbuffer.

When I am calling drawpixel on either buffer I set my modelview to the identity, projection to identity and call glotho(0,1,0,1,-1,1); and set the rasterpos to (0,0,0,1); But it only works when rendering to the main buffer?

[JustHanging]

Hi,

The halfway depth thing works great, altough I've only used it for alpha-based shadow maps. I don't know how to do it for depth textures, though, but since you seem to be getting the depth buffer to main memory at some point anyway, you might as well average the depth values on the cpu and bind the result as a texture. Or then it's just too slow. If you store depth in alpha you can do it just by blending, but you'll lose the precision.

However, if you get artifacts with 24bit depth and optimized near/far planes, I doubt that it's the depth precision that is the actual problem. Make sure that you:
-Add some bias to the depth map, preferably with glPolygonOffset
-Don't have any ambient light when adding light contribution from the light with the shadows

Insufficent resolution also creates problems on the silhouettes (as seen from the light) of the object. This may look like a depth precision problem, but it's not. Increasing resolution won't remove this completely, I've gotten rid of it by using the color channel of the shadow map to make a smooth step on the silhouettes. It's kind of like what I'm doing here, only blurring inwards: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008781.html

-Ilkka

[Korval]

I tried rendering with front face culling instead of back face culling, but I still had artefacts, just on the back of the model instead of the front.

The reason that "front face" culling works is because the back face shouldn't matter in terms of shadow-vs-non-shadow. Because a back-facing polygon is facing away from the light, you should be able to tell it is in shadow from a local lighting calculations.

However, that assumes that the fragments aren't being culled by the shadow map test. What I mean is that you must be doing the compares in the per-fragment processing, not using a special depth-compare extension.

However, as to your particular method, why are you using glDrawPixels at all? You should be rendering your front and back tests to a texture, averaging by rendering those to a third texture (averaging in the fragment shader), and then using that to shadow map.

BTW, are you using "perspective" shadow maps? If not, do a Google-search on this modification to the shadow mapping technique; it can clear up a lot of artifacts and shadow "aliasing".

[JustHanging]

Originally posted by Korval:
BTW, are you using "perspective" shadow maps? If not, do a Google-search on this modification to the shadow mapping technique; it can clear up a lot of artifacts and shadow "aliasing".
Have you ever tried it out, or seen a demo? All I've seen is the original paper which mostly considers limited lighting conditions (always one light obove the camera), some posts from people not getting it work, and a short web page where the writer had found out, that it only looks good fron certain viewpoints and creates serious depth precision problems.

My guess is, that it's great for outdoor/sunlight situations, but other than that, its more of a pain-in-the-ass thing than an actual improvement.

PLEASE somebody prove me wrong http://www.opengl.org/discussion_boards/ubb/smile.gif

-Ilkka