Friday, April 1, 2011

DirectQ Update - 1st April 2011

Been doing some more work on lightmaps and I'm thinking about how I want to evolve them in the future. One thing that has tickled my interest a little in the past is implementing something like software Quake's surface caching system, but using dynamic textures located in hardware. Now that I have lightmap updates running quite fast, the potential of being able to update textures this way would be a shame to pass by.

The way I'd see it working is that you'd have a set of really huge textures - something like 4096 x 4096 perhaps - which you'd then use as a texture atlas (like how scraps and lightmaps are currently done) and write in the results of colormap lookups. Then you use those textures for rendering with, which should give a good colour and lighting quality that approaches that of software Quake but with many of the advantages of a hardware renderer, such as automatic perspective correction and cheap bilinear filtering. You'd also quite neatly bypass problems like non-power-of-two textures in the original game data.

Of course it would mean that video RAM overhead would be rather large, and that all texture data would need to be kept in software. You'd also need to do miplevel selection in software too, but on balance I think it should be an acceptable tradeoff. Today's PCs are more than fast enough, and resources are cheap and plentiful.

The biggest problem I can think of is how you would handle external textures and RGBA lightmaps. The initial implementation is probably not going to support these, as the first priority will be to get the basic procedures working. Once that's done I could look to finding a good solution for these, with perhaps RGBA lightmaps taking priority.

External textures, by the way, were the reason why I went for 4096 x 4096 as the surface cache texture size - it obviously needs to be large enough to support most reasonable external texture sizes.

So all in all it's definitely an interesting idea, and a new bunch of challenges worth pursuing. Ever onwards!

6 comments:

Ron said...

Wanted to let you know that the underwater flickering bug I mentioned a few weeks ago (here) still appears to be present in RC3. I've uploaded two screenshots, normal.jpg and frameflash.jpg, and a video (MP4) for your viewing pleasure.

normal.jpg is the normal underwater appearance while frameflash.jpg is the single frame 'flash'. In the video, there are two flashes right before the one second mark and another two near the 18 second mark. Only seems to happen when I'm moving and not while I'm stationary or simply panning around.

This is on an HD 5850 with Catalyst 11.2 drivers.

mhquake said...

I don't see it too well on the video, but comparing the screenshots what it looks like is that the engine is reverting back to the old sludgy-brown underwater contents colour when you're crossing certain leaf boundaries.

mhquake said...

I just did a rounaround of that part of e2m1 without seeing anything. Could you perhaps record a demo of it happening? That would be very useful and I'd be able to find out what's causing it right away.

mhquake said...

...and was that a vispatched e2m1 by the way?

mhquake said...

No need for a demo; fixed it.

Ron said...

Nice!