Especially for omnidirectional shadowmapping depth cubemaps would be ideal. Currently I can fake this by allocating a color cubemap and then writing a pixel shader which writes the depth values into that map, but I’d really appreciate a native depth cube map format for this (especially now that there’s the fbo ext). The arb_depth_texture spec explicitly claims that depth cubemaps are not supported and left for a future extension (mainly because of the double use of the 3rd texcoord component for depth comparision and cubemap lookup).
Do you know better workarounds and do you support this idea?
Hmm, I read the relevant part in his speech about depth cubemaps. So he is basically saying that depth cubemaps are not a good idea because they are slow and eat a lot of memory if used with 50+ lights if you render each map at 2k x 2k x 6. I agree that the bruteforce approach he mentions is not (yet) feasible. But what’s wrong with having different sized cubemaps from big to small? You’d use the small ones for lights that are rather unimportant (small on screen space with Carmack’s heuristic) and you don’t even need to render each face if that’s not necessary.
What Carmack’s doing is essentially over-optimizing if you take into account how future hardware is developing. His technique also won’t work with 50+ lights if he is going to do shadows for each one. It only matters how much fillrate I am going to consume, it doesn’t matter whether I store my results in cube textures or normal (maybe non-pot) textures.
That’s why I think depth cubemap textures are needed.
-Matthias