Odyssey space has "too much contrast" - breaking down the rendering of a frame

OP, that was an excellent post breaking down what going wrong. Well, at least as far as I could follow it. It certainly wasn't a TL;DR for me, more like Too Technical I'm Not Quite Following All of This post.

In your opinion, how can they fix this. I saw at several points you indicated that it was too late to fix the issue, but I never gathered where it could be fixed.
 
This is why I would love a dev to come on a stream to show us what's going on here. Not to lay blame or expose problems, but rather as a "this is why we're doing things this way, and this is what our end-goal is supposed to look like and why."

Still makes me scratch my head that if the pipeline is supposedly incorrectly applying gamma (or insert terms I'm unfamiliar with), that this wasn't caught during initial development. The lighting is so different from Horizons, it's not difficult to distinguish. But I'm not going to armchair dev and claim to know better than professionals. If this lighting is intended, I'd love to know why it's changed so much, and why it appears that the contrast slider was cranked to 11. Design decision? Aesthetics?
 
I wonder if this set of issues is why there is such inconsistency between portraits generated in Odyssey relative to Horizons when identical customized XML RGB sets are used to mod the HUD colors.

Super thanks to the OP too!
 
Glad this thread has surfaced again. This is one of the most significant graphical issues that hasn't been officially acknowledged. Like others have said, not to lay blame or point fingers, but simply so we can have some assurance that it's acknowledged and/or there's a proper fix in the works.

I'd like to add that I think there was some serious tweaking going on all the way through alpha, and between alpha and release, where the biggest degrading to the HUD happened. I could have sworn that the HUD became vibrant and had a gorgeous bloom pass on it right at the end of alpha, so I went back through my screenshots and, sure enough, it was looking absolutely fantastic. Then, when EDO officially dropped, it was dark and washed out.

Here's 3 screenshots showing what I mean. All on 100% brightness, gamma setting at default:

nkxPbxi.jpg


Top: Late alpha (I think it was the final build we got)
Middle: EDO launch
Bottom: Update 5

It's somewhat better now in Update 5, but it still feels like something is very off, and it's nowhere near as bright as it was in late alpha/Horizons.

Anyway, props to OP for the research.
 
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.
working from home during a pandemic.

I had the same epiphany about the Outfitting, I realized it wasn't badly designed/implemented, but bugs that prohibited the correct module filtering, which I guessed might be down to communication issues.
So was that the stations' module storage, or the station module store, or the ships module storage, or shop modules?
 
working from home during a pandemic.

I had the same epiphany about the Outfitting, I realized it wasn't badly designed/implemented, but bugs that prohibited the correct module filtering, which I guessed might be down to communication issues.
So was that the stations' module storage, or the station module store, or the ships module storage, or shop modules?
Yeah... debatable. I lost a G5 multicannon when swapping stored item because the UI revert back to "sell old module", and there is no confirmation (or even buyback when it's from stored module) for when you sell an engineered item.

Now I'm legit scared everytime I need to use the outfit UI.
 
I thought cockpit look realistic before update 5
Nice led lighting under panels etc.
Darker cockpit, like car inside a car at night.

After all we are in space

Now I feel like driving my car at night with the internal light on
 
I thought cockpit look realistic before update 5
Nice led lighting under panels etc.

Now I feel like driving my car at night with the internal light on
Ah, the usual FDEV way.
We need a couple more iterations, it will be ok-ish by update 6 hotfix 5.
 
I would like the lights to come on when engines go off. Like when you open a car door sort of thing.

Be darker like pre update 5 while flying
 
I thought cockpit look realistic before update 5
Nice led lighting under panels etc.
Darker cockpit, like car inside a car at night.

After all we are in space

Now I feel like driving my car at night with the internal light on
There were times and ships where the dashboard was literally invisible.

Lightning was all over the place and still is. They just shifted the issues around. Space too dark ? Push gamma to the max, but on the other hand it's too high in the other half of the game.
Cockpit too dark ? Well, now it's a christmas tree.
Smoke too bright, and station interior too dark ? Don't worry, now it's way too bright everywhere !
 
Last edited:
Why did they brighten the interior and darken the skybox? That is, as some say, like turning on the cabin light in a car driving at night. It makes it easier to find your bottle of cheap wine in the cup holder, but harder to see the road. Bad combo.
 
I would like the lights to come on when engines go off. Like when you open a car door sort of thing.

Be darker like pre update 5 while flying
Blame people who are inexplicably more interested in seeing the inside walls and struts of their cockpit over what's going on outside.

It was light when there was actual light sources outside to make it so, say when in a starport or near a star. As you say, and as I have said multiple times, it just makes sense for the lights inside the ship to be switched off when one is out in PITCH BLACK space.

Also as has been stated before, who drives around at night with their internal lights on?

The way lighting was changed to me seems to make rather a lot of sense, as in it's pitch dark when there are no light sources. OK I will say there should be some universal ambience generated by the starfield and that increases as one enters dense regions, but in Horizons it was silly how bright dark areas were.

Also the strawmanning of our arguments in somehow wanting universal darkness. No, we want it to be dark where it should be, not everywhere.

The actual issue is ground bases do not have enough articificial lighting in them at night. I mean that could be acceptable in special circumstances like stealth missions, or when the base is powered down (but it is wrong to have a small army of enemies patrolling the base at this stage).
 
I've referenced this thread in an Issue I opened with FD regarding gamma balance, as though there has been lots of forum feedback about it I don't think an issue was raised. Please upvote! https://issues.frontierstore.net/issue-detail/42493
I've been trying to bring up this thread as much as I can when it's relevant, but it doesn't seem to help. This thread is the most comprehensive investigation into the rendering issues I've seen yet, but FDev seems to continue to act like it doesn't exist.
 
I've been trying to bring up this thread as much as I can when it's relevant, but it doesn't seem to help. This thread is the most comprehensive investigation into the rendering issues I've seen yet, but FDev seems to continue to act like it doesn't exist.
I mentioned it to a CM in the Update 6 thread (and a couple of times before that without a response), she said this thread was "on the list". Now that they're suddenly considering the issues fixed in Update 7, I'm afraid that they neither acknowledge this thread nor know how to fix it.
 
I mentioned it to a CM in the Update 6 thread (and a couple of times before that without a response), she said this thread was "on the list". Now that they're suddenly considering the issues fixed in Update 7, I'm afraid that they neither acknowledge this thread nor know how to fix it.
It looks like they will only work on issues that are reported in the issue tracker. So like a good employee I went in to it last night and looked for this specific issue, didn't find it, and so I created it. Now it needs enough people to confirm that they can reproduce it before it's considered real I guess, and then enough people have to vote for it so it shows up on their top 20 ... there may be prayers to Grom and ritualistic dancing required as well, but let's just start with the first two things. Would you mind contributing to the issue? https://issues.frontierstore.net/issue-detail/42493
 
It looks like they will only work on issues that are reported in the issue tracker. So like a good employee I went in to it last night and looked for this specific issue, didn't find it, and so I created it. Now it needs enough people to confirm that they can reproduce it before it's considered real I guess, and then enough people have to vote for it so it shows up on their top 20 ... there may be prayers to Grom and ritualistic dancing required as well, but let's just start with the first two things. Would you mind contributing to the issue? https://issues.frontierstore.net/issue-detail/42493
You're probably right, but I still believed them when they said they had taken note. I contributed to the issue.

Heya :) I've replied to a few comments on lighting today so there's a theme here for sure! I do have a list of notes to have conversations on regarding further lighting issues and so on and this does already sit within them. As usual, I can't make specific promises to things yet until I have further discussions BUT it's on the list :)
 
Back
Top Bottom