Anti-alias vs upscaling vs post-processing

[Woakes]

So I noticed some serious jaggies on the lift doors.

https://steamcommunity.com/sharedfiles/filedetails/?id=3027297251
After fiddling around with the AMD upscaling, with no success, the MSAA x4, the native supersampling 2.0, I couldn't fix the jaggies issue.

However, turning off the Ambient occlusion DID solve the problem.

Pretty much everything in the above picture is turned off, from Anti-aliasing, AO, Bloom and despite the rough jaggies onscreen, I find it a little annoying that the post-processing SSAO (on medium settings) is adding large pixelated jaggies regardless of anti-alias settings, as well as banding on the walls of the lifts.
like where in the process of anti-aliasing should your post-processor kick in before or after?
As this feels like it's after, and degrading the image quality.

 

[Morbad]

Lower quality AO settings use lower resolution scale for the effect, which looks bad itself, and AO in general increases contrast around edges and corners, which the AA methods the game uses have serious problems with.

That said, disabling AO doesn't fix the majority of the aliasing problems, and the AO settings are configurable enough (via the override) that it can be setup in a way that doesn't increase jaggies.

 

[Woakes]

I'm still waiting for when GeForce Experience claims EDO has been driver-optimized

For jaggied and anti-aliasing, I find it unfortunate that ED has a lot of hard edges that need to be at an angle, and not many "natural" shapes to fudge around with. (Minecraft)

Orbit lines have got to be a "personal" pet peeve of mine, for their jaggies or getting faded out with aliasing.
Namely because of the "drawn on" 1-pixel thick nature of them (presumably).
I assumed they are drawn on with a simple "line-to" command and scrubbed every frame and drawn on again(?)
I used to do a lot of flash work back in 2005-2013, and getting the assets pixel-perfect so edges did not bleed onto the neighboring pixels was a priority when it came to "fine lines 1 pixel in width".
You could see sloppy workmanship when buttons' edges got smeared or appeared jagged.

Ironically, if the lines were 3-4 pixels thick, you could smooth the edges better, or have 9 sliced scaled textured.
And add in maybe a leading and trailing edge so Pilots know what is the inside or outside of the orbit lines...a common suggestion since the game's launch.

If you think about it, how are planetary rings rendered? You can get very thin rings in-game perfectly smooth in comparison to the orbit lines.


Sometimes it's just sleight of hand tricks.
like thumbnails for NPC's should be done during the docking animation, not after you try to pull up a menu and it hangs there.
Market information, That stuff could be done during the "load" between star systems. I mean it's text information, it's not chewing up vast resources.
Sure it can update during the menu call-up, but during that process, the previously loaded-in market information could appear slightly miss-colored so the player knows it's "cached" and might be out-of-date information (disable buy/sell until the present market value has been confirmed).
But just to keep a sense of uninterrupted "flow" to the proceedings.
but you know, they have intellectual heavy weights simulating a galaxy and some big intellectual brains rolling in and out of the Cambridge area....what does an old burnt out web-monkey know?

 

[Condor]

I can agree that disabling AO (my was set to medium) can reduce the certain amount of jaggies on close surfaces

 

[Morbad]

These are my current AO settings:

    <HBAO>
        <High>
            <HBAO_RadiusInMeters>8.4</HBAO_RadiusInMeters>
            <HBAO_NearRadiusInMeters>2.1</HBAO_NearRadiusInMeters>
            <HBAO_NearDistance>200.0</HBAO_NearDistance>
            <HBAO_PowExponent>2.0</HBAO_PowExponent>
            <HBAO_Bias>0.3</HBAO_Bias>
            <HBAO_BlurSharpness>1.0</HBAO_BlurSharpness>
            <HBAO2_PowExponent>3.0</HBAO2_PowExponent>
            <HBAO2_Bias>0.1</HBAO2_Bias>
            <HBAO2_BlurSharpness>16.0</HBAO2_BlurSharpness>
            <MultiSampleCount>2</MultiSampleCount>
            <ResolutionScale>2.0</ResolutionScale>
        </High>
    </HBAO>

Not perfect, but not adding to or accentuating any aliasing on geometry.

Orbit lines have got to be a "personal" pet peeve of mine, for their jaggies or getting faded out with aliasing.
Namely because of the "drawn on" 1-pixel thick nature of them (presumably).
I assumed they are drawn on with a simple "line-to" command and scrubbed every frame and drawn on again(?)

Orbit lines are actually geometry, as revealed here.

 

[Woakes]

Another bonus factor with removing the AO is the annoying "re-draw" after closing down menu's, for example at the pioneer supplies.
Edit:
I'm a bit of a layman with regard to rendering techniques, but that post talks about altering the shader that draws the lines, that's not necessarily "actual geomertry" which in my head is "in-game-geometry" which is then calculated and drawn in 3D space.
This is a shader drawing the line, you can see this dude showing off what line-drawing with shaders can do (and yes they can be anti-aliased).

Source: https://www.youtube.com/watch?v=cU5WcrU_YI4

Personally, I always felt, aliasing was "solved", back when Apple (spits in the corner), introduced the world to the "retina" display, where 2K (or was it 4k) screen was squeezed into size of a standard 1080p screen.
So you had something hyperbolic (as I can't remember the exact details, and I can't be bothered looking it up) 50-inch screen on a 22-inch screen by literally making the pixels really small, and your eye couldn't see the pixels at all. No Jaggies whatsoever, you were just rendering at a higher resolution on a more pixel-dense and compact screen. You literally had native MSAAx4 but without the calculations.

A small problem was It just required the world to adopt it as a standard.

 

[Ian Doncaster]

You literally had native MSAAx4 but without the calculations.

Without the MSAA calculations, yes. You still need to be able to render the scene at 4k rather than 1080p at the desired framerate, though - relatively easy for a word processor or web browser, more of a problem for a real-time 3D game though starting to get more practical recently.

A small problem was It just required the world to adopt it as a standard.

High pixel-density displays were available long before Apple set up "retina" and are available from other manufacturers now. The standards needed to get software to work at various pixel densities were well established (if somewhat ignored back before Apple made higher-density displays more common for consumer use, and a bit dubious now).

The problem is cost: having a smartphone or even a tablet or small laptop screen with pixels half the edge (quarter the area) of a standard monitor is one thing; scaling that up to a full-size monitor is another. They exist. They're not cheap even by "gaming computer" standards.

 

[Morbad]

I'm a bit of a layman with regard to rendering techniques, but that post talks about altering the shader that draws the lines, that's not necessarily "actual geomertry" which in my head is "in-game-geometry" which is then calculated and drawn in 3D space.

If it's made out of triangles, it's geometry.

Personally, I always felt, aliasing was "solved", back when Apple (spits in the corner), introduced the world to the "retina" display, where 2K (or was it 4k) screen was squeezed into size of a standard 1080p screen.
So you had something hyperbolic (as I can't remember the exact details, and I can't be bothered looking it up) 50-inch screen on a 22-inch screen by literally making the pixels really small, and your eye couldn't see the pixels at all. No Jaggies whatsoever, you were just rendering at a higher resolution on a more pixel-dense and compact screen. You literally had native MSAAx4 but without the calculations.

A small problem was It just required the world to adopt it as a standard.

Rendering four times the pixels is the equivalent of 2x or 4x SSAA (depending on how it's counted), which is significantly more demanding than 4x MSAA.

Supersampling (e.g. just throwing pixels at the problem), is still the best kind of AA as far as IQ goes, but it's not practical in most vaguely modern titles, because the performance is too low.

To functionally eliminate Odyssey's aliasing, I need to run the game at 10k resolution at my normal display size and viewing distance. This results in somewhere in the ballpark of 20 frames per second on a watercooled 3GHz RTX 4090.

You can certainly upscale and filter an image, that was rendered at a lower resolution, to reduce jaggies and this is commonly done today (it's what TAAU, DLSS, and FSR do), but it still has overhead, and there is no replacement for native render resolution when it comes to the general detail of an image (though image reconstruction can preserve/improve select areas).

 

[James Spartan]

@Morbad , in which file do you edit HBAO values you're showing ?

 

[Morbad]

@Morbad , in which file do you edit HBAO values you're showing ?

"GraphicsConfigurationOverride.xml" normally in "%LocalAppData%\Frontier Developments\Options\Graphics\" or thereabouts.

 

[James Spartan]

Ah ok ! Before I asked, I looked in this file but noticed no section for the HBAO settings. Now I suppose I just have to add it in my file. That's right ?

 

[Morbad]

Ah ok ! Before I asked, I looked in this file but noticed no section for the HBAO settings. Now I suppose I just have to had it in my file. That's right ?

Yes. The override is normally empty, you have to add what you want to change. Indentation is important.

 

[James Spartan]

Ok thanks !