I'm starting to think about how I'm going to handle fog in DirectQ now that most everything else has been ported to D3D11. Previously I'd built a second copy of all shaders with fog toggled on in it, but with the enhanced capabilities of the new API there are a few more options available.
An obvious one is to just use some branching in a single copy of all my shaders. There is a slight extra overhead in the case where there is no fog, but things get really simpler as a result.
A second option is to capture the depth buffer as a texture and blend that over the scene, using a fog formula on it. It appeals as it means there is no overdraw case whatsoever (only pixels that are in the final scene get fogged) but falls down on account of sky being awkward to handle and some objects that should be fogged not writing to the depth buffer (shadows, particles, certain alpha surfaces).
Finally I could just say "fog is always on" and rely on a density of 0 to not show any in cases where it isn't.
I'm thinking of going with the last option ("fog is always on") initially, see how that works out, and if it causes any problems revert back via branching and then a second copy. The appeal of this is that there is a clear and easy reversion path with minimal changes between each step. Ultimately I want to get away from having a second copy of all shaders, but I'll do it if I have to - it's just the final resort. I'll take the performance hit if it's small enough.
The depth buffer approach has massive appeal to me but there are enough corner cases where it's going to break that it's not worth pursuing.
In other news, I recently got to test on some D3D10 (not 10.1, just 10) class hardware and the good news is that I'm now able to drop the entry level back to D3D10. It's still using the D3D11 API but is able to use feature levels to run on D3D10 hardware, which includes older NVIDIA and AMD/ATI cards as well as a huge range of Intels dating from the original introduction of Windows Vista - over 5 years ago, in other words. I think saying that "your graphics hardware must be not more than 5 years old" is not unreasonable.
Sunday, March 4, 2012
A Question of Fog
Subscribe to:
Post Comments (Atom)
2 comments:
What about the edge-case of translucent water and inside/outside-water fogging?
I know translucent water is on the "wasn't on the table in 1996" list. But the added visual consistency would greatly benefit immersion, and frankly I think it would be a killer feature. I guess volumetric fog would be needed to fix that in a non-hacky way though?
It's something I've never been able to find a reasonable solution for. In Quake you've got cases where an object may be partially in water/partially out, and they're the ones where anything I've tried in the past breaks down - the loss of visual consistency caused by such an object being incorrectly fogged/coloured (or incorrectly not fogged/not coloured) is much higher than the loss caused by just not doing it at all.
A modern game would resolve this by building everything from scratch to be able to support it properly - including map and model formats. Alternatively it can be resolved by just not allowing the player to ever go underwater.
These are not options for Quake so it's easier to handwave it by just saying that the tint is caused by the medium your eyeballs are in.
It's also the case that water in Quake doesn't actually obey the laws of physics. It can be on ceilings, suspended in mid-air, anything! Any solution would have to work with this, and a solution that breaks with standard ID1 content is probably not worth pursuing.
Post a Comment