Graphics Programming is So Rewarding
The incredibly complex reading and work necessary to make changes most people won’t ever notice.
Figured I’d start with what was leading to all of the subsequent changes I’m going to mention. I was rolling back the first iteration of my physically accurate camera renderer (basically an alternate, accurate, though more expensive set of post effects for things like film grain, lens flares, projection/distortion, etc.) — which I detailed a bit of the high-level plan for over on our Facebook page. And I got into the game, realized the volumetric fog wasn’t properly jiving with trueSKY, so figured out how to fix that, and voila.
Now Steel Hunters lives in Orange County. And it’s a fairly volatile scene composition where: trueSKY is bright and intense (which is accurate), but it also means that UE’s tonemapper and, more notably, the eye adaptation goes bonkers. The histogram-based luminance algorithm compensates for the difference in lighting values and environment shading values by blowing out the scene beyond recognition.
That said, reducing trueSKY’s output intensity or modifying the sun’s rendered intensity/size results in a scene that looks drab, flat, and thoroughly awful.
And then the volumetric lighting (through UE4’s new volumetrics solution handled through exponential height fog) makes things even more complicated. The eye adaptation issue, naturally, ends up making the volumetric fog scene-encompassing with color values that are even remotely similar to the existing lighting. So it ends up being, at the moment, almost component red, and then its brightness reduced to a level where shafts still show, but the fog doesn’t look like Frank Darabont’s The Mist.
Some of this requires external help to start to reconcile, so yesterday I took a break from the game backend systems and camera lens development to focus on materials, BRDF shading models (I’ve wanted to expose alternate models to the material editor for a while and this was a good chance), and then some non-destructive (in terms of PBR accuracy/consistency) ways to add more interesting/slightly-exaggerated detail to my metallic and mech shaders.
The primary issue with my metallic shaders right now is that once they’re in-scene (and not just viewed in the mesh preview window with ideal image-based lighting situations), they become incredibly difficult to look anything but black from even moderate distances. Which, again, goes back to the issues in the first post.
But, that said, I still wanted to generally improve upon the mech shader, so I exposed more BRDF shading models to the material editor; namely the oren-nayar model for diffuse reflection and rough surfaces. This is the Before Shot.
And this is the After Shot. The difference is subtle, but, going between the two, actually fairly significant It doesn’t resolve the darkness issue whatsoever, but I still preferred the results (and it’s not all that much more computationally intense).
And just to prove that I’m not making this up.
More generally, I wanted to see how the two models would affect general surfaces. I chose this random brick material I found (that doesn’t even use my standard shader at the moment) — a mistake, given that it’s not the best texture data — to record a bit of a toggle between the two models.
And don’t feel bad if you look at this and don’t see any difference at all. There is one, and the oren-nayar model is an improvement, but I would be astounded if people ever picked up on it.
And that’s graphics (and, in general, game) development for you! Incremental improvements that are incredibly complex to research and easy to screw-up equation implementations all resulting in an incremental change to visuals that maybe but almost definitely will result in an average viewer thinking “yes, this is the same video game in every way as it was yesterday.”
I can’t currently run the game while I deal with some externally-caused crashes, so hopefully by the time you see this you: A) don’t see this message, B) don’t have to deal with an incredibly small and compressed image.
Anyway, this isn’t applied at any low-level shader because, for the most part, it’s not necessary, but this is somewhat of an amalgamation between the commonly-used Schlick approximation and bits-and-pieces of other models to make the calculation a bit more expensive but accurate. It’s currently only affecting the blue material surface on the mech, but this alteration will likely be proliferated throughout my “master shaders” because, as Filmic Worlds points out: “everything has fresnel”.
This calculated value is then piped out (currently in grayscale form; not sure if I want to do any amount of blending with the base color yet — likely not) into the material’s emissive output so that it doesn’t have an impact on the PBR calculation/result integrity. I have dynamic, in-shader values already prepared if I have to scale down the intensity of this value as lighting conditions change over time, but I haven’t run into that yet because: crashing since this screenshot.
It was a five-second thing to test, but I wanted to see how the Oren-Nayar BRDF model would affect the terrain (as most of the map is untextured/checker-material after my scorched-earth approach to asset reorganization). This is the Before Shot (Detail Lighting view, no base colors):
And this is the After Shot. I don’t know what I was expecting, but it was nice to see that that it didn’t blow out the lighting anywhere as much as it was before. Again: not a change most people would ever notice or care about, but I CARE.
And, finally, how could I leave out the star of the show: the video of swapping between models ~every 2 seconds. Just to show you, you know, HOW DEDICATED I AM TO QUALITY.
Follow-Up: The following video wasn’t in this article originally (occured about twelve hours later, actually), but I feel it represents a very big, obvious change! SO IT’S NOT ALL LITTLE STUFF!
It’s, instead, a sea of sky monsters.
