TES Skyrim 0.143

[mallimoosh]

In the future i'll stay with new ssao only improving it's performance, precision for small details and mixing code changes.
Working on reflections now, experimenting with antialiasing tricks.

Whew!

I really believe that your work on SSAO at the expense of AA has been a core contributing motivation to the ongoing pursuit of identifying and advancing alternate AA implementations such as SMAA and FXAA. The work done with SweetFX in conjunction with ENB being my current prime example. The community continually amazes me with it's ingenuity. ENB SSAO is one of the foundations that the entire Skyrim graphics enthusiasts community is built up around.

+ 1000 on that.

On a side note, just finished adapting K ENB to 0.143 (moved my lazy ass a bit) and eagerly awaiting for SSAO code improvements to be finished, since actual .143 kills my performance compared to .132.

Thanx for all Boris, good luck on your work.

I for one will be happy to get hardware AA back. SMAA is great for low or mid end rigs but nothing holds a candle to 8xSSAA. It's the only thing that kills aliased reflections and grass.

[ENBSeries]

I will start ban everyone who ask for hw aa. Are you all idiots or what? How many times i must repeat the same? Nobody read docs, so fuck off.

[Zinthros]

HW AA is bad anyway because of transparencies / vegetation ...

[Svarog]

HW AA is bad anyway because of transparencies / vegetation ...

SuperSampling at 2x will do that Vegetation job. At 2x it's not so performance hungry.

[ZeroKing]

@ Boris
People don't get that, with deferred code, SSAO will be less accurate if hardware anti-aliasing is applied AND have a terrible impact on performance. I suppose it's due to the amount of data that has be collected in the first pass that has AA applied on it that may cause such an issue, especially separating data into the G-buffer, which I bet causes an increase in memory bandwidth. Sort of defeats the purpose of having better SSAO methods if it will look terrible with hardware AA. I think it should just be made aware, since clearly people are still a bit on the annoying side trying to argue about getting hardware AA back even though it'll actually look bad, applying both the AA and deferred SSAO together.

In my opinion, just stick with the deferred code. Sure, post-process AA like FXAA or SMAA can't beat MSAA or SSAA, but whatever. I'd rather sacrifice that for tighter and better SSAO

Besides, it's sort of difficult (or impossible) to make hardware AA work with deferred code on DirectX 9 games, isn't it? I know, at least by literature, that games supporting DirectX 10 or 11 has ways of making deferred shaders work with hardware AA. Correct me if I'm wrong, I'm quite curious about it

Quality SSAO + post-process AA > Okay SSAO + hardware AA

[ENBSeries]

Deffered with msaa impossible in dx9. And to make ssao compatible with msaa in 0.119 and older versions, it was not rendered to antialiased target, normals generated from depth by my special method which remove wrong lines where aa applied. And downsampling antialiased color to non antialiased twice, with transparent and without transparent objects, this is very costly by memory bandwidth, for aa x4 at 1080p is about 120 mb transfer. For complex indirect lighting (which is always on with deffered) i drawed each object to another render target without textures, it's one more antialiased surface with copy data from it for processing. So much effort for aa? Supersampling is faster in this case, even deffered. I know only one solution to make aa work with deffer, but this trick only possible when you develop game and can change all shaders.

[XenoKratios]

I will start ban everyone who ask for hw aa. Are you all idiots or what? How many times i must repeat the same? Nobody read docs, so fuck off.

This.