PDA

View Full Version : What do you think aboud dual parabaloid shadow mapping ?



DSA
01-18-2004, 05:48 AM
Hi!

What do you think aboud dual parabaloid shadow mapping ?

Is it really useful ?

Is it really robust solution for omni directional lights ?

Korval
01-18-2004, 12:53 PM
Well, if you only have to make 2 renders, and can somehow get the distortion to happen on the GPU, fine. If you have to do CPU pixel manipulation, or have to do 6 cube-map-face renders to make it work, then cube map shadow buffers is the superior method.

Jan
01-18-2004, 02:02 PM
You do know, that cubemaps are not supported as depth-textures Korval? That makes depth-shadows for omni-directional lights quite useless at the moment.

Jan.

Korval
01-18-2004, 02:31 PM
You do know, that cubemaps are not supported as depth-textures Korval?

You are aware, of course, that you don't need a depth texture in order to do shadow mapping?

jwatte
01-18-2004, 04:54 PM
ID shadow maps can be done with cube maps on DirectX 8 type hardware.

Depth shadow maps can be done with cube maps on DirectX 9 type hardware (as they support floating point textures; just move depth into luminance and be happy!)

Ostsol
01-18-2004, 04:54 PM
That's true, but AFAIK there aren't any other texture formats with sufficient precision for a 24 bit z-buffer. A 32 bit floating point texture comes close, with a 23 bit mantissa, but only ATI support floating point cubemaps, at the moment.

Korval
01-18-2004, 08:49 PM
Depth shadow maps can be done with cube maps on DirectX 9 type hardware (as they support floating point textures; just move depth into luminance and be happy!)


As Ostsol mentioned, nVidia cards don't support arbitrary float textures. They only support float texture rectangles, which are a different texture type from cube maps.

Me, I don't care that my code would only work on an ATi card. nVidia will support it eventually.

Tom Nuydens
01-18-2004, 11:35 PM
... Or you can pack a 24-bit depth value into the RGB components of a regular cube map. Unfortunately, using whatever type of cube maps loses you any native PCF support the hardware may have.

DPSM requires finely tessellated geometry for it to look correct, but other than that It Just Works. It doesn't require any workarounds to overcome hardware/API limitations, and it gives you everything that regular shadow mapping gives you. ID shadow maps won't give you self-shadowing, and any type of depth-based approach with a cube map won't give you PCF unless you implement it yourself.

-- Tom

Humus
01-19-2004, 03:34 AM
Who says you need 24 bits precision? In the vast majority of the situations a 16bit fixed point texture is more than enough. In small scenes you can even get away with 8bit.

Tom Nuydens
01-19-2004, 04:00 AM
Originally posted by Humus:
Who says you need 24 bits precision? In the vast majority of the situations a 16bit fixed point texture is more than enough. In small scenes you can even get away with 8bit.

Sure, but it's still the same story. You don't have native depth texture support in these formats, so you need to use a fragment program as a workaround to be able to generate a shadow map in these formats. This is more costly than doing a Z-only render to a standard depth texture.

-- Tom

Korval
01-19-2004, 05:11 AM
DPSM requires finely tessellated geometry for it to look correct, but other than that It Just Works.

What is DPSM? I imagine that SM is for shadow map, and that D is for depth, but where does the P come from?


and any type of depth-based approach with a cube map won't give you PCF unless you implement it yourself.

Which, for cards I'm interested in in terms of shadow mapping (ie, my 9500Pro) is no different than using ARB_shadow. So, for me, whether or not the extension can be used for <insert texture type> is a non-issue. PCF isn't worth the cost on platforms that don't support it.

DSA
01-19-2004, 05:38 AM
DPSM - "Dual Paraboloid Shadow Mapping".


How fine geometry must be tesselated to avoid artefacts ?

Is there another problems with a DPSM ?

JustHanging
01-19-2004, 10:22 AM
More finely than you'd want to http://www.opengl.org/discussion_boards/ubb/smile.gif But you can have seperate tesselations for each light (tight tesselation is only needed close to the light), that allows you to get away with much looser tesselation.

More complicated models like humans typically don't require any additional tesselation.

-Ilkka

DSA
01-19-2004, 11:26 AM
Separate static tesselations for DPSM lights sounds stupid. I need DPSM for dynamic lights. For static light i can use lightmaps
without any tesselation. DPSM firstly needed for completly dynamic omni directional light sources. As i understand only one problem for DPSM - high tesselation ?

JustHanging
01-20-2004, 02:56 AM
Another potential problem is, that you might get a seam where the two maps meet. This is especially true for soft shadows. I'm letting the maps overlap a little and blend them together to ensure a seamless transistion.

If your lighting really is completely dynamic, maybe you're better of with static tesselation. But per-light tesselation isn't exactly stupid either. There are much less polygons to draw. You can typically re-tesselate one light per frame, and if you have several moving lights, you can tesselate one at the time and draw the rest with their old tesselation. This allows you to have several moving lights with small extra cost.

I personally think it's a bit stupid to optimize for the completely dynamic case, since in typical scenes most of lights don't move anyway, and taking this into consideration can lead to a huge speed increases in the average case (which may still include some of the lights moving).

Using shadow mapping for static lights makes sense too, as there are still usually moving objects, which will cast and recieve proper shadows. My engine doesn't make a seperation between dynamic and static lights, though, moving a light just causes a small speed hit. Think of a dungeon lit by torches on the wall, most of the time they're static, but you can pick up any of them and walk around with it if you like.

-Ilkka

harsman
01-20-2004, 05:53 AM
While I haven't implemented DPSM it seems likely that the aliasing you have to fight against when using shadow maps will be even more prominent when using DPSM due to the way the algorithm allocates texture space for the surrounding environment.
Doesn't the difference in spatial resolution depending on where on the sphere a part of the scene ends up lead to aliasing?

JustHanging
01-20-2004, 06:09 AM
Yeah, aliasing is a problem. The difference between different areas of the texture isn't that bad, I can't see the difference really.

However, the fact is, that to cover the full 360 degree enviroment, you need a lot of resolution. 2*512*512 is a practical minimum, but it's quite aliased, so often you have to use at least 2*1024*1024 and even then small details don't get correctly shadowed. This all isn't helped by the fact that you always have some unused texels in your maps since the paraboloid projection is circular.

Luckily you can use lower resolution for the other hemisphere, for example many lights don't have to light detailed objects above them, so you can use a lower resolution map for the higher hemisphere.

-Ilkka