Sunday, January 10, 2010

Shadows

I finally knuckled down and tackled the disgusting piece of hackery that is Quake's shadow code. For now my objective was "just get them working" and after a few issues relating to integration of the old shadow code with my new setup and the order of matrix transforms they came out OK. They're quite fast but can never be as fast as rendering without them.

At the moment I haven't bothered with properly projecting them on to the plane or stretching them off to one side of the model.

I'm in two minds about this shadows thing. Carmack wrote in the original GLQuake readme that they weren't meant to be very robust, but just a neat little trick that he pulled off quickly enough and was rather fun to look at. Software Quake doesn't have them. Original GLQuake shadows didn't work right on sloped surfaces, and nothing outside of shadow volumes or shadow maps will work right on steps. If a model is just outside of your FOV it's shadow will abruptly disappear, even if it had been stretching half way across your screen in the previous frame. They hurt performance. They have nasty looking hard edges.

What this is leading up to is that I'm thinking of removing r_shadows at some point in the future. They're a novelty trick that makes you go "gee whizz" for about two seconds. If shadows are to be done at all they should be done right (DarkPlaces), and right now that's beyond the scope of DirectQ. Shadows (GLQuake style) really belong in the same big bag of discarded nastiness that mirrors, lack of fullbrights and lack of overbrights have long since been confined to.

I'll leave them in as they are for now, but don't be too surprised if you see them go sometime.

0 comments: