Graphics Update... BGolus and Varrak cleanup rampage

It's been a caffeine-fueled couple of weeks here in the graphics cave at Uber, and BGolus and I have been busy. I decided it was time to take a brief respite from optimization, and focus on fixing up some of the annoying visual issues (and missing features) that we have in the game. Some of these are actually out in the wild (I believe...), and are quite subtle so you might have missed them. Others are coming soon.

Warning: This might get very technical. I apologize in advance for any drowsiness reading this might cause.

The first thing I did was to fix issues with normal map compression. A while ago we pushed most of our content over to using DXT compression for textures. This saves a lot of space (4x or 8x, depending on whether the texture has an alpha channel or not). But there's some downsides if you, for example, forget that normal maps don't compress well by default [hangs head in shame]. This was not a visible issue on almost all planets, except on metal planets with the hard crease normals, and there, it was... well... bad juju.

The fix here was simple(ish): I updated the content pipeline to swizzle the texture channels so the green channel stores the y component, red and blue store 1.0, and the alpha channel stores the x component. You lose a component, but the fact that normals are guaranteed to be unit length means you can easily derive Z when sampling, by just doing the equation z = square_root(1.0 - dot_product(normal.xy, normal.xy)). The end result? We end up with close to non-compressed quality normal maps (well, closer, anyway), and the metal planet looks much better. See exhibit a, below:



Next, BGolus pointed out that our GBuffer normals (that's the normal data that gets built up prior to the lighting passes - for more info, go read up on deferred shading) were horrible, since we were using an 8-bit per channel texture to store world-space normal data. Since the vectors are normalized, you only actually get to use around 2% of the precision of the 3 bytes stored; as a result, you can get banding which looks ugly and makes artists sad. See exhibit b, below:


The smart guys over at Crytec figured out a really nifty way to work around this, though, using a technique called "Best Fit Normals". This uses a texture lookup to figure out the best non-normalized vector to fit our normal to, and use that instead. At the lighting phase, we just normalize the value (which we were doing anyway), and hey presto - we get up to 97% of the available values. That's a bit good. See exhibit c, below:



Another thing that's been annoying a few people here for a while was some artifacts that showed up around shadows, especially around the edge of planets. This was due to precision issues at glancing angles, where shadow/non-shadow depths would pop back and forth, and cause hatching. I don't have a picture of that, but I'm sure anyone who played the game with shadows noticed it. BGolus worked out a fantastic solution, the name of which I forget, which makes things look a lot better. I'll leave it up to him to talk about that one (wouldn't want to steal his thunder...).

Last, but definitely not least, our lead artist has been asking for a particular feature for a Long Time. The feature in question is something called "Ambient Occlusion" (click the link if you're interested). This can have a massive impact on the visual quality of graphics; but it's one of those effects that if it's there, you don't really notice it, because it just looks right. Well, I'm pleased to say that as of today, I integrated the latest and greatest screenspace algorithm for ambient occlusion - something called Scalable Ambient Obscurance. The paper is here. It's some pretty heavy reading (I have keyboard-key-shaped indents in my forehead where I fell asleep reading it last night). But if you're really, really curious, then clickity...

Anyway, it was a fun and interesting challenge to actually implement it (by "fun" and "interesting", I of course mean "challenging" and "my head hurts"), but by golly I got it working. Words don't do it justice, so here's some pictures:

First, a nice sunset, with no SAO:



Now with SAO:



And some metal planet action:

(Without)



And on:



Anyway, we had fun doing this stuff, so I thought some of you might be interested in reading about it. Obviously, if you're reading this part, you're still awake! Congratulations...

SAO is not hugely expensive, so on most mid to high end systems I doubt you would notice a difference. And we should see most out all of these in a build coming out... soon...

SAO is scalable ambient obscurance, which is a newer form of ssao. It's faster and more stable than hbao. I believe the latest call of duty releases have used it.