davepermen,
Am I hearing you right? You are actually defending shadowmaps
Oh well, on the subject: Not only do you not have to send all the geometry 6 times, but since lights ussually have small radiuses it is a heck of a lot less geometry than the whole scene. You would not have to render geometry past where the light shines, and point lights like, say, a light bulb or the glow of a rocket, are not very bright, and effect very little geometry overall.
It would be so nice if the next gen cards supported floating point cube buffers!
Actually, if you read my post in other thread about shadowmaps, you would know that I pointed out that distance is not important in shadow mapping. All you really need to do is to map a function which will uniquely identify each pixel and then look for mismatches. Because of limited precision, you should be able to use such a function to find near matches.
So, you could quantize the x,y,z light space position of the pixel into an r,g,b color cube map and then use a fragment program to calculate the distance between the shadow map r,g,b and the actual lightspace position determined from some other method (say, a 3D texture or inverse transform of the window space coordinate into lightspace, idunno, be creative ^_^)
If the distance is small, then the pixel is lit, if the distance is too far away, then it is in shadow. This is a lot like color index shadow mapping, but per-pixel.
It would still be nicer to have a float cube map and just have the float result there without losing any precision to quantization.
Hmm, perhaps the fragment program could encode the distance into RGBA and then decode it from that so that you could use the full 32-bits of precision. That would even have more usable bits of precision than a floating point number.
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.