Friday, June 25, 2010

I think the current version of the renderer is now complete...

Translucent water surfaces are a total PITA to get done right. Once again no real standard way of handling them evolved over time, leaving us in a situation where we have to deal with a combination of r_wateralpha and explicit entity alpha on world surfaces, inline brush model surfaces and instanced brush model surfaces, and decide how things interact in SP versus MP games in maps that have been VISed for translucent water versus maps that haven't. Yuck.

My current decision here is that explicit entity alpha will always override r_wateralpha. Everything works seamlessly on all the different types of brush model (so you can use translucent water on ammo boxes if you want), and I'm not going to do anything about r_wateralpha in MP games - mostly because there is no way I have ever found of reliably detecting if a map has been VISed for translucent water.

Sigh - why didn't we just decide to use the Q2 SURF_TRANS33 and SURF_TRANS66 flags and be done with it all those years ago?

What else? I've removed a lot of complexity from the renderer by just deciding for now that all vertexes used by everything are padded up to the same size. This is a purely temporary measure until I get deferred vertex stride buffering working in a manner that's pleasing both to me and to older 3D hardware. So the D3D9-specific stream offset I was using is no longer there.

In retrospect I should have been happy to start out that way. There's a lot to be said for keeping things primitive and simple (sometimes so primitive that they're saying "og! og!" and banging stones together to make fire) at early stages of code redevelopment. On the other hand the downside of that is that if you go too primitive you'll probably have to rearchitect the whole thing all over again later on. There's a knack to finding the sweet spot.

So where we're at now is that I need to exhaustively go over all of the various components here and make certain that there's nothing obvious I'm overlooking. Index transfers need optimizing. Then I bring on variable vertex strides one step at a time. Start with sky because it's the first thing drawn so it will be immediately obvious if things aren't working and go from there.

Then there's that idea I had for higher performance again, but this time I'm keeping my damn fool mouth shut until such a time as I know it's going to work.

Till then.

0 comments: