Steel Hunters - Color-Grading/Post-Stack Tuning

This post was originally posted at its lovely home on Joy Machine's website. Check it out some time <3

Generally, I do all of my game work on my primary monitor (Dell 27″ S2716DG) which I’ve run through a couple of color/brightness/etc. calibration tools. I have not done the same for my under-resolution — due to outputting to multiple displays from a laptop — Samsung 32″ (S32D850T). That monitor has not received the same love, since it’s already not running its intended resolution, so I figure it’s a lost cause until I can build a proper desktop computer.

That said, it’s a great test for a more “common” monitor display setup, as outside of the art/design/game development/film industries, there aren’t a whole lot of people with properly-calibrated displays.

Steel Hunters was basically 20% barely-discernible black color output, and that was in a still image, much less during gameplay. Though gameplay would have the benefit of dynamic lights illuminating the area (potentially).

Anyway. I wanted to fix that. So, because I needed a new article on this site (or so I’m told by the team), I decided to make this project my article. And also my way to not just blindly tweak post values because: A) I needed reasoning for this article, B) I have a tendency to just continue the cycle of tuning to my primary monitor.

An attempt to solve both these problems is to just define a bookmarked position in-editor (so if it crashes, I don’t lose this reference point) which has a complex scene composition — a wide variety of exposure values — and balance iteratively and take notes every step of the way. And a screen shot of each annotated iteration from the same bookmarked perspective at 2x editor resolution, which ends up being 3722×2656.

All of this arose entirely out of playing Ghost Recon: Wildlands for a week straight and then binging Metal Gear Solid 5: Phantom Pain upon realizing that I never got anywhere even close to completing it. The most striking difference between the two games, which sounds negligible at first, is how they handle scene lighting at night. In Wildlands, the scene is barely visible at night if you’re not actively in a lit area (through spotlights, car headlights, streetlights, etc.). I assumed initially (and the resulting conclusion doesn’t negate this) that my, somewhat ironically, completely uncalibrated television display near a window lacking proper blackout curtains was the cause of this. But playing in the same conditions over the course of no-it’s-not-important-how-many-hours-were-spent-on-these two days of MGS5, it became clear that this may have actually been a design decision.

Spoilers: benefit of the doubt tossed in  Wildlands‘s general direction may be wrongly-placed. RESULTS IN THE ARTICLE CONCLUSION!

Granted, it also ended up taking about five times as long as it would have otherwise. C’est la vie.

STARTING POINT: POST_WORK_ITER_00

All items to follow have been changed in a later iteration, based on this starting point, so here are their original values for posterity.

ITERATION: POST_WORK_ITER_01

Generally trying to improve dimly-lit/heavily-shadowed area visibility, while also tweaking the results of the bloom a bit as it’s in the stack and doing things, just nothing really of note.

Trying to alter the tonemapping curve (which is to set to “filmic” in UE4, which I believe is ACES) to expose the dimly-lit areas rather than just tweaking the color grading values themselves — as those are applied later in the post stack and degrade overall composition quality.

CHANGED THIS ITERATION

ITERATION: POST_WORK_ITER_02

The bloom is way too omnipresent to the point of no longer highlighting/accenting bright areas and, instead, just applying an entirely different camera lens (totally altering the intended composition style).

Also, no values I’m using are really highlighting intentionally-overexposed emissive materials, so using the gas sign as an example of a reasonable value.

CHANGED THIS ITERATION

NOTE: Also updated the following materials/material instances:

ITERATION: POST_WORK_ITER_03

Dig the changes to the bloom, restoring the changes from _iter_01 to see how it fits into the original scene.

The resulting image is, overall, a bit lighter in the more heavily-shadowed areas, but nothing that’s really an experience-changing difference.

CHANGED THIS ITERATION

RESTORED TO BASE

ITERATION: POST_WORK_ITER_04

The resulting bloom changes and injection of another overexposed item in the composition with the gas sign material change actually ended up with a slightly more balanced final composition than I expected. Though, still not enough to really resolve the issue for most players/viewers. Scratch that, had the wrong initial values written down because I started this article after iteration 1. The lovely Jan on our team sanity-checked for me and this resulted in _iter_03 having a more desirable bloom effect, but no change whatsoever in composition darkness/brightness. Which is… Far more what I would have expected given that the responsible parameters were reverted to their original state.

So, opening the HDR Histogram to visualize the scene exposure values showed this:

The heavily-overexposed GAS sign is very intentional, and the overexposure of the sun and surrounding clouds (for those that are new to TRENT’S WORLD: all things are dynamic always forever, including the results of the trueSKY-based cloud renderer) are not explicitly intentional, but also not surprising nor undesirable overall. Checking our existing min/max brightness values in the Eye Adaptation step of the postprocessor stack against UE4’s defaults just proved-out that they were good changes for us to make.

So, yeah. Huh.

ABRUPT CONCLUSION

While checking out the skylight/sunlight (directional light) values/settings in our “world” actor (generally controls atmospheric/environmental world systems, lighting included) resulted in me needing to use my Event_trueSKY_Calibrate editor function to restore my scene settings. Apparently editing a component within an actor instance musses up something in our lighting pipeline. Anyway, the resulting point of this entire post is: if you have a function to calibrate your entire scene to a specific setting/time-of-day, best check it before starting an article where you dictate your color grading/post-stack tuning steps. Because this is what the calibration yielded:

And, yeah, while the problems that started this whole endeavor are still occurring in the same areas, the scene composition is changed enough that it somewhat negates the meticulous step-by-step process that would’ve led to a solid conclusion.

Oh well. On the plus side: I didn’t have to make it to iteration fifteen like I was worried I would.

Next time maybe I’ll just video capture this whole thing.

OH, YEAH, THE MGS5/WILDLANDS THING

Metal Gear Solid 5 provides a somewhat-hybrid Night-Vision/Thermal device (view mode) for the player to use in dimly-lit situations. And at higher upgrade levels, even adapts well in broad daylight (I’m not there yet).

This is somewhat different from Ghost Recon: Wildlands‘ separate Night-Vision and Thermal devices (separate view modes). The NV device in Wildlands is a usable option from the very get-go, but the Thermal device is gated behind a skill progression tree — implying the Thermal device is either more advanced and requires more player knowledge of the game to use properly or is, generally, more useful than night-vision. The resulting gameplay experience is… A little of both? Thermal is largely for discerning enemies (known and unknown) amidst the incredibly complex scene that is typical for the game. So, maybe, the impetus the game is providing for its difficult-to-discern dim lighting scenes is to ensure you’re using your secret agent devices like you’re supposed to.

In MGS5, I end up using my Night-Vision Goggles because I want to and think they’ll be beneficial… But their use isn’t necessary to play the game at any time of day in varying lighting conditions.

Given my experience with the MGS5 compared to much more time over a longer interval with Wildlands, I’m inclined to think that Wildlands didn’t bother enough with the kind of experiment I just [attempted] to run.

UPDATE: LOCALIZED TONEMAPPING

This isn’t going to be the kind of thing that really gets remedied with a late night or anything, but I remember adoring this series on Localized Tonemapping by Bart Wronski (here’s part two).

I think, at the end of the day, balancing this test composition without some kind of substantial change to how tonemapping/eye adaptation is handled at a low-level is going to be a Sisyphean endeavor. I have a few experiments I’m still going to run (though not accompanied with devlog posts as I do them because, well, this happened) to see how best I can skirt by the issue in the short-term, but if the time ever opens up to really gut UE4’s tonemapping and replace it, localized tonemapping seems like a neat starting point. And, regardless, the idea of a more flexible, adaptive tonemapper would seem more appropriate for a game where it’s incredibly hard to predict what kinds of situations players will get into, much less balance compositions well for them using a “best fit” parameter configuration. No, I will not get obsessed with this topic. Not right now. But… soon?