Step 17: Finally, this is where the trouble begins, as the skybox and the
stars are rendered into the
same image that also holds the cockpit
geometry view. From this moment on, the values in those pixels are doomed:
No amount of clever tone mapping can bring them into comparable contrast
ranges, after they have been baked together.
View attachment 229939
Also it seems and if the skybox might already have its tones gamma mapped,
but I'm not sure about that. But if the skybox is pre gamma mapped, this
would be a mistake.
Still at this point the image still looks okayish. Barnards Loop is
clearly discernible and also the Milky Way is faintly visible. We can blow
up the tone ranges, and also bypass to see how this look with and without
gamma and different contrast.
View attachment 229940
View attachment 229941
Step 18: In this step the HUD is drawin in, element by element. Here
I only show the final result.
*Of particular note is, that the HUD
elements look as they do in "normal" screenshots if gamma bypass is
enabled for the debug display.* This means that all the HUD elements are
rendered in with the basic gamma ramp already pre applied. So if we
presume that the render target so far is supposed to be in linear RGB,
then the HUD elements will inevitably get gamma transformed to a higher
power, which is not correct; the result will be a far larger contrast on
the HUD elements with things being either really bright, or really dark.
View attachment 229942
and here with an additional subsequent gamma transform
View attachment 229943
After this
the final tonemapping pass is applied.
And this is where the
digestive end product hits the rotary air impeller. In the pixelshader for
this tonemapping step is applied what could be understood as a gamma
transform. The resulting image, in linear RGB already looks as the
presumably desired end result. It still looks okay, the HUD is readable,
albeit a little bit overcontrast and oversaturated, we can still clearly
see Barnards Loop and a hint of the Milky Way. I'd not deem this
"perfect", but perfectly acceptable within the constraints of a product
release.
View attachment 229944
However, because the image is untyped, the graphic system will
apply a gamma transform of its own, with the familiar, unpleasant result.
View attachment 229946
One thing that stands out about this tonemapping step is a constant found
within the pixel shader: 64500. That value is awefully close to 65535,
i.e. 2\*\*16-1. My guess is that a (junior?) developer had trouble with
the value ranges, dumped an image, took its maximum value x, punched 1/x
into their calculator and rounded to the next multiple of 100 (why 100 and
not 128?).
View attachment 229947
Now remember back to the first step, the cubemap: That thing looks good.
And it's aligned with the ship, so clearly this cubemap is not
prerendered, but rendered somwhere else. So these frame captures don't
tell the whole story, there are even more renderers involved there,
operating independently.
Among "experienced" grey beard developers it's common knowledge, that the
code structure of a program reflects the organizational structure of the
entity that developed it. These frame command dumps are a reflection of
the code structure that produce them. So by second order indirection this
allows me to take a few guesses. The whole thing reeks of a communications
problem. Within the generation of a frame there seem to be (at least)
three different "teams" working on the same thing: The people who develop
the astronomical renderer, the people who develop the ship's cockpit
renderer and the UI renderer (which produces that HUD) team, and I got the
impression, that there's a severe lack of communication between them. It's
at the interface between them, where the mishaps occur.
