[QUOTE=tikotus;1287300]EDIT: It looks like the depth texture is cleared halfway through the shadowing pass. The ground is rendered in more than one pass because of the vertex count. Seems like one of the passes succeeds while the other one leaves polygons unshadowed.
Only once in a few seconds there is a frame when all polygons are shadowed correctly, and once in a few seconds the depth texture shows correctly. When ever the depth texture shows correctly, the shadows are also correct, but not vice versa. To me it seems that the depth texture is cleared before all meshes are rendered, except sometimes.[/QUOTE]
Good find! That’s definitely something you can work with.
When you say that the ground is rendered in more than one pass because of the vertex count, how do you know that? Are you talking about you are rendering it in multiple passes, or under-the-hood the GPU is rendering it in multiple passes?
If the latter, then I think you’re saying that when rendering into your shadow map, the geometry you’re submitting for your ground pass is overrunning the size of the tiled primitive buffer passed between the vertex and the fragment pipes, causing multiple read/rasterize/write passes to be performed when rendering to your shadow map (aka a pipeline flush).
If so, then this is going to reduce your performance of course, but unless you’re rendering with MSAA when the pipeline flush occurs, this shouldn’t generate any rendering artifacts unless there’s a bug involved (either in your graphics driver or in your app).
Here are a few things you might check into:
[ol]
[li]the logs for your graphics driver to see if it indicates what the size of that driver primitive buffer (associated with the framebuffer) is, [/li][li]look for ways to tune up the size of that primitive buffer in your graphics driver configuration, and [/li][li]try reducing the amount of geometry you’re sending to your shadow map to see if you can get it to consistently work. That would at least help you nail down the root cause. [/li][/ol]
What I’m wondering is if your driver experiences a primitive buffer overflow, is it properly busting up your rendering into multiple passes properly, or is it possible it’s just dumping the whole primitive buffer in the bit bucket when it experiences an overflow? The logs emitted by your graphics driver may help answer this question.