No way to apply shadow-mapping for point lights?

Originally posted by Nakoruru:
[b]solarforge,

Saying that you only have to render the lights that shine in the same direction as the view vector (I am assuming that you mean that they have a positive dot product) is completely wrong. You can have shadows that are cast towards you from a light in front of you. The light vector and the view vector in this case are in opposite directions.

[/b]

Ummm, no… what I said was lights facing away from the view vector that are behind the cameras view plane don’t need to be rendered… ie: up behind your head facing the opposite direction.

Leathal.

Originally posted by tayo:
[b]The problem with your (vvery good) idea on cube map is the filtering. The best filtering method for shadow map is nearest neighbor filtering and it is not implemented for cube map. Maybe, it can be faked on a fragment program…
Another way is to use big resolution (but a cube map with 512x512 texture per face should be expensive…)

[/b]

I doubt about nearest filtering, I’ve seen it on NVIDIA demos.

A nice thing with shadow maps, is that you can apply AntiAliasing when rendering them, that smooths the edges of the shadows and gives really better results.

I should point out here that I have an example on my site of using cubemaps to do shadowmapping of point lights using radial distance instead of depth.
http://www.ronfrazier.net/apparition/index.html?appmain=research/advanced_per_pixel_lighting.html

Originally posted by GPSnoopy:
[b]
I doubt about nearest filtering, I’ve seen it on NVIDIA demos.

A nice thing with shadow maps, is that you can apply AntiAliasing when rendering them, that smooths the edges of the shadows and gives really better results.

[/b]

Sorry i made an error, filtering for shadow mapping is percentage closer filtering not “nearest neighbor” (i do too much photon mapping stuff).
Actually, it is implemented on the nvidia cards since the GeForce3 but it will not work with the “radial distance cube map” method.
Indeed, using AntiAliasing can resolve the problem but it is not free in terms of performance.

Sorry Solarforge,

I even read it twice to make sure I did not misunderstand you. I guess I missed the word ‘behind’ twice.

Thats a good point, and an optimization I had not thought of.

EDIT:

Actually, the reason I had not thought of it is that I was thinking in terms of Perspective Shadow Maps. With perspective shadow maps, you only need to render one shadow map if the point light is outside of the view frustum (in fact, thats the only time in which perspective shadow maps have been discribed to work).

[This message has been edited by Nakoruru (edited 09-11-2002).]

Originally posted by pocketmoon:
[b] How would you go about using radial distance instead of depth ? Would you use the light->fragment vector to index into the cube and compare the radial distance ?

[This message has been edited by pocketmoon (edited 09-10-2002).][/b]

thats your sentence, wich is correct, but, imho, you sounded like thats impossible so i asked you whats wrong… well your sentence is right, nothing wrong with it

quote:

Originally posted by tayo:
The problem with your (vvery good) idea on cube map is the filtering. <SNIP>

NV30 FP

r300
its yet there, dude, don’t wait

Originally posted by davepermen:
r300
its yet there, dude, don’t wait

Ok, so how do u implement any kind of filtering method with your shadow cube map and a r300 (or nv30) ?
The main problem of shadow mapping is aliasing, because it is an image based method. The problem of point lights seems secondary to me.

Originally posted by davepermen:
r300
its yet there, dude, don’t wait

Two questions on the method :

  • are u sure u can interpolate the light vector direction per fragment, it does not seem correct to me. maybe u have to recalculate it with the fragment position and the light postion, no ?
  • with your method, u can’t use percentage closer filtering implemented in hardware, do u have any replacement using r300 or nv30 fragment progam ?

i still believe that the problem with shadow mapping is aliasing, and point lights issue is secondary.

Perspective shadow maps ( paper ) remove much of the aliasig problems with shadow maps.

Originally posted by tayo:
[b] Two questions on the method :

  • are u sure u can interpolate the light vector direction per fragment, it does not seem correct to me. maybe u have to recalculate it with the fragment position and the light postion, no ?
    [/b]

Easy one, interpolate the actual position, send the light posistion as a fragment shader constanst. Do the rest in the fragment shader … just sub, dot3, rqs, mul, done

Originally posted by tayo:
[b]- with your method, u can’t use percentage closer filtering implemented in hardware, do u have any replacement using r300 or nv30 fragment progam ?

i still believe that the problem with shadow mapping is aliasing, and point lights issue is secondary.[/b]

You can implement any kind of filter you want in the fragment shader, so this isn’t a problem at all. You can get results even better than using traditional shadow mapping.