Game Development Community

Wow... stencil shadows are a problem...

by Brett Fattori · in Torque Game Engine · 01/12/2004 (8:04 am) · 4 replies

Been working for about 2 weeks now on implementing robust stencil shadows. Just got the first renders from the engine last night and it wasn't at all what I expected (LOL) -- but it's getting there! The actual implementation is pretty slick with edgeList creation on mesh load (each mesh contains an edgeList), the StencilShadow object handles all the setup, and rendering code. Stencil shadows can be toggled globally and on a per object basis... That way, for fast moving objects you could select either no shadow (already in the engine) or shadow maps (current method) instead of stenciled shadows. Plus, if you can guarantee that the camera will never move within a shadow's volume, you can turn off Z-Fail shadow detection. Finally, scissor rectangles for even more speedups will be implemented.

I've had some issues with learning how the OpenGL pipeline works at the same time as getting this code into the engine. One big thing I keep forgetting is that it's glEnd(); not glEnd;... Doesn't throw a compiler error, but it blows away the canonical state.

Now, onto my actual question... Point light sources are obvious in that they have a point of origin, an attenuation, a color, etc. Vector (infinite) light sources, on the other hand, have a direction, color, etc. I understand the whole shadow volume calculation stuff, but everything I've found so far talks about point lights only. The all refer to the light having a position. How does one go about handling vector lights with no position? Should I just be creating a dummy position some far off distance away? Or am I misreading the mPos component of LightInfo as junk when it's actually a point of origin?

Thanks for any help.

- Brett

#1
01/12/2004 (8:15 am)
I'd say ignore directional lights.. But thats just me :)
#2
01/12/2004 (8:57 am)
Just found some interesting stuff explaining some of the information I've been looking for. A presentation about 4D homogenous notation clarified a lot. I have a better understanding of why it's using 4D notation now. But I guess I need to dig a little deeper to find out why it's still not quite right.

- Brett
#3
01/12/2004 (8:59 am)
Me, I'd probably just approximate with a very distant point light, but then again, I'm pretty lazy about that kind of thing.

Your other choice is to extend the volume along the light's direction, instead of along the vector from the light pos to the vertex. I don't know how you've got the code set up now, but this would probably require you to special case it.
#4
01/17/2004 (9:56 am)
Well, you're probably projecting the image onto a surface, right? You're going to need some sort of vector like (vertPos - lightPos) in your examples. Instead of doing that, just use the light vector.