VRS - Smoke and other Alpha transparency fixes
Variable-rate Shading VRS is in the graphical settings for Metro Exodus, it's used so that shaders can be scaled down when they are far away from the player.
so turned off smoke could be a work-a-round, but it's not fixing the root issue.
Again massive speculation here :
How can any system know when smoke is too far away or behind something to be rendered correctly, when the current system may still have problems with its
occlusion and culling
Still haven't figured it out. CPU is around 35-65% usage while GPU is sitting at around 40%. ¯\(ツ)/¯
If I'd had to guess, the culling is still broken because I see so much stuff flicker in and out and something is constantly being updated on the GPU and it seems like the bus is choked (which shouldn't happen). Horizons runs fine.
i.e. the "bug" that Kay pointed out in the first alpha as to why the performance was poor because of a bug they were trying to lock down in the occlusion and culling, so they just "turned it off" for the alpha.
They might have turned it back on, they might not, was that bug fixed??
This is what I've been maintaining since every update had graphical fixes but performance is still poor and and everyone claims it's shaders or lighting which is the issue,
when instead it was something like the AI triying to map all the rocks outside of the Settlements "stamp" because the AI wasn't culled to just inside the settlement because....the culling system is perhaps not working as intended?
So going from personal experience, the internal spaces of Starports and Settlements are pieced together by the procedural generation from what the Background sim says is required, and when the alpha was released I still had my old GPU and memory card.
And I got a whole slew of graphical issues, such as "seeing where the joins where" and crossing the thresholds of the joins to indeed choke the FPS.
Flying around planets we got the high-detail planetary rocks rubberbanding in and out of view as the game camera can't judge distance/height/depth correctly???
My time burning out as a developer
Once upon a time, I put some stuff together for flash and unity projects that were "dynamic" in nature, with graphical elements lego'd together with other graphical elements.
Being an unvetted programmer with undiagnosed Dyslexia at the time, I wound up doing my head in.
Usually, it was
1) artists not sticking to the naming conventions of their layers correctly aka their exported Assets NOT being set up correctly.
2) me not "reading" naming conventions properly ergo the code not being able to find the correct layer properly.
3) the code that was supposed to Enable/disable, turnOn/TurnOff, did more things inside those Methods( or not enough things) to the correct layers or they themselves were being overridden or not overriding similar named Methods by another code.
So semantically, we trust what we perceived.
The code is fishing for "AssetName" and "some asset" is found and the code tried to turn "On/off" from the multiple layers of the multiple assets joining together. Reading through the log files or trying to step through the code, everything looks like it's behaving but something is clearly NOT going to plan.
My Debug Solution.
If it was "me" and my burning-out brain was still melting down by stress and anxiety when I would WORRY myself into a deeper pit of anxiety resulting in a desperate attempt by creating an overkill debug tool that takes everything back to basics, to circumvent my own dyslexia and inability to decipher lots of complex code, or naming issues created by myself and/or the rest of the team.
I would go insist on a UnitTestBot.
so as the locations are procedurally generated. UnitTestBot throws down a grid of nodes.
The nodes then literally catalog ALL models and assets and their hierarchy of layers caught between them and their neighbor and the status of said assets
ALL culling layers are searched for and shut off. (If naming conventions have adhered to, then this shouldn't be an issue)
Then the test is performed again.
Then report between the disparagings or compiling links between the nodes should start to shake loose the issues.
The second level would be that the nodes then start to turn off where there connections are clearly not an issue.
Leaving you with a group of internal and external nodes.
The third phase would then to move the internal nodes to doors / centers of rooms, to be used for environmental mapping
Take some sample data of settlements and starports layouts, and get devs to recreate them by hand, and then compare the handcrafted work with the code driven work.
