Experimental Stuff

Earlier on today I implemented detail textures and water caustics in DirectQ. This is not something that's going to make it into a release, but it was an interesting exercise nonetheless.

Why not release it? There was a certain cost involved with my current setup that was unacceptable. I'll come to that later, but for now I'll just say that if not for that cost I likely would be releasing it, and that I'm going to keep the code anyway as it's possible that I may resolve it at some future time.

Detail textures were quite simple enough; just a noise texture modulated with the main texture. I played with using an RGB noise texture versus a greyscale one; the RGB texture - while it sounds horrible - actually turned out to look a great deal better at certain texture scales. I also did some experimenting with replicating some TexGen modes in the vertex shader to avoid having to send extra sets of texcoords - it worked reasonably well enough, but could have been better.

Caustics were interesting to do. I didn't go for shiny sparkly caustics like you sometimes see in techdemos, but instead did a moody shifting light effect; well suited to Quake's atmosphere. If I were to come back to this I'd probably do something with shifting the intensity of the actual lightmap textures rather than using a separate caustic texture.

The cost I mentioned was that I had to build separate combinations of shaders for caustics/fog/detail on and off, and startup (and vid_restart) time became prohibitive. In one extreme case DirectQ took a few minutes to start up - ouch. I experimeted with lazy-loading the appropriate shader depending on the requirements of the current scene (and reusing it from a cache if already loaded) but that caused stalls of a few seconds the first time you went into water, for example.

One solution to this might be to precompile my shaders and ship binary versions of them with the engine, but that would require some changes to my build system and would make things awkward for debugging and iterative testing. There are probably other solutions.

In any event, having backtracked I decided to keep the lazy-load/shader cache system but instead of loading on demand I just load the two combinations I currently need up-front. It still causes a slight stall on startup and vid_restart (if you've ever wondered why DirectQ's vid_restart and game changing was a mite slow - that's the reason: shader loading is slow) but it's within acceptable tolerances.

One last thing I did some preliminary work on is lightmaps. It occurs to me that because I'm using 32-bit lightmaps (D3D textures are strictly 8, 16, 32, etc bit) I have 8 bits spare that I could do something useful or interesting with. I have one specific idea for that, so let's see what happens...