@Deadly, I agree on the normal maps. Using glossmaps and dedicated normalmaps will help too. You can find some screens on the net for now. I'm not planning to implement a feature to turn off normal mapping, though it wouldn't be such a big problem to do so ofcourse. Let's call it a future 'nice to have'.
My goal is to also show off per light volume shadows if possible=) I'll use either the color or alpha buffer to act as stencil buffer. What I'm planning:
* In pass 1 I'll just render the scenery to zbuffer, probably in 320x240 res, I'll also determine what lights are visible there.
* In pass 2 and 3 I'll draw the volumes for each visible light in 320x240 res, though due to limited bit depth of alpha buffer, I need to switch between drawing front faces and back faces more often resulting in more rendering passes than when using a real stencil buffer. I don't assume that will be a huge performance hit though. For each light, the resulting drawn volumes will be exported to textures.
* In the final pass I'll draw the scenery in high res. For each light, the shader will look up the corresponding volume texture to determine if a pixel is lit by that light.
I think the Wii can handle it, but the huge amount of lights in Quake might spoil it. We'll see!
@Tron: reading those lights shouldn't be a problem. I currently read the lights from the entity dictionary clientside anyway. So using a rtlight file instead of the dictionary is possible. Again, a 'nice to have' to me. My priority is to get things up and running using the original level designs. Mainly because you can use any missionpack with it then. So if it turns out that Quake has too many lights, using stuff from Darkplaces might be an easy alternative, but I'd rather look into creating an algorithm that combines lights that are close to eachother to reduce the count..
Just some notes you could try:DRS said:Iron, I realized I only answered your question like... half... or so...=) Higher resolution stenciling would be possible ofcourse.