Why do we need shadow maps?

Started by
3 comments, last by Matias Goldberg 11 years, 1 month ago
Bit of an odd question. In a deferred shading renderer, when you render a point light (for its lighting pass), you have the world space position of the light and the depth value from the viewer's camera to the pixel, from which you can reconstruct the world space position of the pixel. Typical shadowing techniques do a first pass to render the depth value from the light to the pixel and then send that to the lighting pass. Usually it looks something like this:

return length(LightPosition - input.WorldPosition) / FarClip;
If we know the position of the pixel and the light, can't we just do this in the lighting pass:

float shadowFactor = pixelDepth < length(LightPosition - pixelPosition) / FarClip;
I'm sure if this worked someone would have figured it out already, but I can't see why it wouldn't and it's bugging me.
Advertisement

It should probably be clear why shadow maps are necessary based solely off the observation that light occluders are often off screen.

If we know the position of the pixel and the light, can't we just do this in the lighting pass:
float shadowFactor = pixelDepth < length(LightPosition - pixelPosition) / FarClip;

Where did the value pixelDepth come from? pixelDepth needs to be the scene depth as rendered from the light... i.e. the shadow map.

It should probably be clear why shadow maps are necessary based solely off the observation that light occluders are often off screen.

Ah, of course. Silly me. I always overlook things like that.

If we know the position of the pixel and the light, can't we just do this in the lighting pass:


float shadowFactor = pixelDepth < length(LightPosition - pixelPosition) / FarClip;
I'm sure if this worked someone would have figured it out already, but I can't see why it wouldn't and it's bugging me.


There are two possibilities:
1. pixelDepth is the depth from the GBuffer, in which case your formula makes no sense (if the object is further from me than it is from the light, it is shadowed).

2. If pixelDepth is the depth from the light space, then it must have come from a shadow map. Sure, what's confusing you is that you can retrieve the data from the GBuffer and turn it into light space, and obtain "pixelDepth". However in that case your formula would always pass (never shadow). The detail you're omitting is that in the algorithm pixelDepth may not be from the obtained from the object you're evaluating, but rather from another caster that is close to the light (and as pointed out, that caster can be off screen, but even if it isn't, your assumption won't work).

This topic is closed to new replies.

Advertisement