Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA

  • francentu3456
  • Topic Author
More
6 years 9 months ago - 6 years 9 months ago #1 by francentu3456 Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA was created by francentu3456
Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIASING) B)
Last edit: 6 years 9 months ago by francentu3456.

Please Log in or Create an account to join the conversation.

  • Marty McFly
More
6 years 9 months ago #2 by Marty McFly Replied by Marty McFly on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
Have you implemented it or do you want someone to implement it??

Please Log in or Create an account to join the conversation.

  • JBeckman
More
6 years 9 months ago #3 by JBeckman Replied by JBeckman on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
To me considering it's TXAA it's pretty clearly a request to add said feature to ReShade.

Unfortunately as a Gameworks API library it's not quite that simple and the effect also works with MSAA and far as I know requires per-game specific implementation.
The other earlier temporal AA solution known as SMAA T2X might be doable if ReShade could reliably get some of the data needed from how I understood discussions around that but it wouldn't be easy and perhaps it wouldn't even be viable as a generic global function.
(SMAA 2X, S2X and 4X requires even more and are probably not achievable at all.)

I'm not too skilled on the actual tech requirements for this myself though, grabbing certain buffer data, access to previous frames and so on, FXAA and SMAA(1x) is probably as good as it's going to get until someone writes something better. (Intel experimented with a variant called CMAA I believe but not too sure how that went.)


Even if the shader code could somehow be taken and implemented you'd still need Nvidia's license terms as it's a Gameworks effect similar to e.g HBAO+ which I believe has also popped up in a few requests although there are some pretty solid AO shaders available by now. :)
The following user(s) said Thank You: 5Alex

Please Log in or Create an account to join the conversation.

  • Insomnia
More
6 years 9 months ago #4 by Insomnia Replied by Insomnia on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
I'm curious if Temporal SMAA is possible. Motion Blur uses previous frames to produce blur.
Would it be possible to apply temporal SMAA with this technique? :)

Like I said I'm just curious.

Please Log in or Create an account to join the conversation.

  • Insomnia
More
6 years 9 months ago #5 by Insomnia Replied by Insomnia on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
The silence here makes me think it's impossible. :D
The following user(s) said Thank You: Exilium

Please Log in or Create an account to join the conversation.

  • Marty McFly
More
6 years 9 months ago #6 by Marty McFly Replied by Marty McFly on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
Motion blur just naively blends current with previous color data. AA techniques need the exact positions of objects in previous frames to exactly reconstruct where a pixel was before. This can only work with some matrices (depends on what you want to reconstruct, view pos or world pos) that ReShade can't access.
The following user(s) said Thank You: Insomnia, RogueFactor

Please Log in or Create an account to join the conversation.

  • RogueFactor
More
6 years 9 months ago - 6 years 9 months ago #7 by RogueFactor Replied by RogueFactor on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
From what I saw there was code on github for an OpenGL implementation of TXAA but it looks very hackish especially on ATi cards.


gist.github.com/bagobor/6452933

Warning: Spoiler!


A little off-topic, but as I watched the Physx portion of this video. When they paused the video to show off the smoke effects from the gun fire in combat, I immediately thought their demo was lagging. xD
Last edit: 6 years 9 months ago by RogueFactor. Reason: Forgot the URL

Please Log in or Create an account to join the conversation.

  • canceralp
More
5 years 5 months ago #8 by canceralp Replied by canceralp on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA

Marty McFly wrote: Motion blur just naively blends current with previous color data. AA techniques need the exact positions of objects in previous frames to exactly reconstruct where a pixel was before. This can only work with some matrices (depends on what you want to reconstruct, view pos or world pos) that ReShade can't access.


What if fakemotionblur code is modified to blur or not blur, depending on the luma and color changes from the previous frame?

I don't know coding but actually started a topic about the idea, hoping someone with shader coding knowledge do it.

Basically, imagine it this way:
1- we set a threshold for luma and color, let's say 25% for both
2A- if a pixel's change is smaller from 25%, compared to the previous frame, then it is just displayed as is.
2B- if the change is big (like a suddenly appearing blue sky pixel among green leave pixels) then it is limited to 25% change and sudden-high-contrast pop-in is reduced to %25 only. It's not a popping bright blue, but a mixture of blue and the previous green, instead. So it's not frame blending. It is taking a pixel's previous color info as a base and limiting the change for the upcoming frame.

The idea could even be developed further with two more additions:
1- including more then a single previous frame, maybe like previous 3 frames and setting independent threshold values for each.
2- also taking into account the neighbor pixels as a rotating triangle and adding additional color merging to the final result. Technically, each pixel has 8 pixels around them. I say "rotating triangle" to ease the calculation and crate more temporal effect like this: /\ \/ < >

Now imagine this with a 1.5x of the screen resolution and with SMAA. This will end any aliasing or shimmering you can imagine. And, since the temporal pixel filtering wouldn't be about blindly merging two (or more) frames, it wouldn't result in ghosting. Only the extreme sharp and sudden glow effects would be effected slightly.

Please someone, consider writing the code here. I can help with every math, equations and even hand draw the transitions to prove that I'm right. I tell you, this will bring any aliasing-fest game, like GTA V, Assassin's Creed Syindicate, to it's knees and would give everyone one more great reason to use reshade. And also would be a good, respectful farewell to MSAA :)

Please Log in or Create an account to join the conversation.

  • OtisInf
More
5 years 5 months ago - 5 years 5 months ago #9 by OtisInf Replied by OtisInf on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
That's way too simplistic. Please see this presentation:
advances.realtimerendering.com/s2016/s16_Ke.pptx
It's the TAA implementation of Uncharted 4. It starts simple, and when they've shown how to do it on a static image, you think "boy, this is easy!", and then you turn to the next slide and realize you have seen nothing yet and things start to go downhill towards 'impossible' really quickly.
TL;DR: you need to know at what location a pixel was in the last frame, then mitigate all kinds of edge cases. In reshade we don't have that info, all we have is a depth buffer (which often jitters so edges are cumbersome) and a color buffer.

Can it be done with still images? Sure, code is likely just half a page, but for in-motion images, no way.

Please someone, consider writing the code here.

Heh the amount of times I've seen / heard that sentence attached to an idea which was considered 'groundbreaking'... :) No offense meant btw, at the idea level things look rather straightforward, but implementing them often makes you realize you've overlooked one tiny detail (or a couple) and solving those turns out to be rather hard (if not impossible)
Last edit: 5 years 5 months ago by OtisInf.
The following user(s) said Thank You: canceralp

Please Log in or Create an account to join the conversation.

  • Chavolatra
More
5 years 5 months ago #10 by Chavolatra Replied by Chavolatra on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
I know it's hard to make quality AA in reshade but then in Nvidia Inspector can to enable AA in games?

Please Log in or Create an account to join the conversation.

  • canceralp
More
5 years 5 months ago #11 by canceralp Replied by canceralp on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA

OtisInf wrote: That's way too simplistic. Please see this presentation:
advances.realtimerendering.com/s2016/s16_Ke.pptx
It's the TAA implementation of Uncharted 4. It starts simple, and when they've shown how to do it on a static image, you think "boy, this is easy!", and then you turn to the next slide and realize you have seen nothing yet and things start to go downhill towards 'impossible' really quickly.
TL;DR: you need to know at what location a pixel was in the last frame, then mitigate all kinds of edge cases. In reshade we don't have that info, all we have is a depth buffer (which often jitters so edges are cumbersome) and a color buffer.

Can it be done with still images? Sure, code is likely just half a page, but for in-motion images, no way.

Please someone, consider writing the code here.

Heh the amount of times I've seen / heard that sentence attached to an idea which was considered 'groundbreaking'... :) No offense meant btw, at the idea level things look rather straightforward, but implementing them often makes you realize you've overlooked one tiny detail (or a couple) and solving those turns out to be rather hard (if not impossible)


None taken :) . I have read the presentation. I'm trying to think simple deliberately.

Main advantage of proper temporal anti aliasing is being able to achieve MSAA or SSAA through time domain. That requires proper object dedection and calculating the motion among frames. However, this info is used for appropriate "blending". When applied correctly, this is by far the best anti aliasing method but it needs to be in the engine, because it requires knowing the vectors as well as pixel center shifting. These are the perfect recipe for perfect anti aliasing, if there is a thing.

My approach is not pixel blending, thus no need for vectors. I propose "clamping" the change.
Please imagine this scenerio;
There are 10 frames, containing only a very very low quality, cartoony 2D tree with dark brown and high green pixels. Inside the green part, there is an opening which is supposed to be smaller than a pixel, and it bleeds light blue, representing the sky.
Through each frame the tree shifts to left by half-pixel steps. Since the movement is half-pixel-sized steps and the light blue opening is sub-pixel sized, this should result in the blue color be visible one frame and invisible for the next. That means, throughout the 10 frame, I'll see the blue sky "flash" 5 times. That is pixel shimmering, or "sub-pixel aliasing" with the technical term.

FXAA or SMAA will do nothing for this type of aliasing as they will they to guess the color from the neighbours and mislead to wrong colors in the end.

Now, let me try to describe my approach; I "limit" the allowed change of a pixel by color and luma, between the current and previous pixel. Let's set this value for %50.

In the first frame the blue opening is visible. In the second, it will not be visible. Our pixel is vibrant green now. On the third, it wants to be blue again. But we allow only %50 change of the base color and luma which is vibrant green. So it becomes a slightly darker blue, with some green injected in it. We didn't blend it, we limited the transition's color and luma value. So, here, we slightly prevented the first "flashing" effect. The original pixel values which were not displayed, are kept in momery BTW.

On the next frame, there is no blue again. However, we have just displayed a blue pixel with an eased transition. So this time, we do the same thing for the green pixel. We limit the green amount and darkening from the previous blue, and it becomes a lighter green then it's neighbours, with a little bit blue in it.

Here we don't fix the geometry, nor the shader aliasing. It just reduces the flashing effect of sudden changes of the pixel color and brignthess. Instead of seeing 5 flashes in a 10 frame journey, I see a blue tint in the middle of the tree, which deceives my brain into thinking there is a gap in the middle of the tree that shows me the sky.

As for the ghosting. Well, technically this IS ghosting :) . But an intended one. Since, the original value is always stored, the next pixel is calculated purely by the original value and there is no risk of too old values bleeding into a newer frames, resulting a trailing effect, which is why blending algorithms need the vectors in the beginning.

Also, it will not effect bright permanent colors, as it is only effecting the transition moments. Once the brighter pixels keep lit, they will be perfectly shown after only one frame delay.

One more thing, this is not solving any geometry or shader or texture aliasing. So it ideally needs to be used with DSR/VSR + FXAA/SMAA. Once the still image is alias-free, the in-between aliasing of the frames can be reduced with this.

Please Log in or Create an account to join the conversation.

  • v00d00m4n
More
5 years 1 month ago #12 by v00d00m4n Replied by v00d00m4n on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
Try to think outside of box - if you have no vectors it does not mean you cant assume them!

just a quite example:
this is frame 1 pixel grid 3 by 3

|   |   |_ |
|   |_ |   |
|_ |   |   |

this is frame 2:

|   |   |   |
|   |   |_ |
|   |_ |   |

_ - is edge (which we detected in previous step which im not discussing) and  - is any other kind of pixels
you can clearly recognise the vector of movement of pixels - they go straight down.

If pixels did not move very far, its not hard detec their movement by spliting whole screen in to greed with some sort of configurable matrix size in which you assume pixels supposed to be same.

So, we got previous frame, we got vector information, we can do sort of Temp AA. Yes its not that precise, mistakes can happen, so this pseudo - temporal AA would not as good as native one, but i think with such per grid cell vector detection we can sort of imitate TAA.

Since its not very fair TAA i suggest to call it PSEUDO-TAA, but just dont say its impossible. Detection of vector should be done with clear edge detection buffers of previous and current frames, we can get this part of code from SMAA debug view and use smaa code for perfect tuning of edge detection and even use depth buffer for more precision, or actually we can improve SMAA shader by adding this PSEUDO TAA step into it and we call it SMAA PSEUDO T2X or SMAA PSEUDO TAA. FXAA could be merged into it as well as alt edge smoothing technique, and we can combine all 3 together in various oders to get best results.
Also, what i think needs to be done - is masking and reconstruction of everything that not considered as edges, with few pixels of margin, to restore pre-TAA sharpness without applying artificial sharpness shader... or we can apply sharpness selectively to those masked zones that are not edges and not few pixels around them, so that sharpness would not ruin AA efforts. I remember thera few shaders in reshade that are separate yet allowed to be used together as few steps of single more complex effect, dont remember the name of it, but we can separate AA and edge masking and put existing sharpening shaders in between.

Anyone want to try to do that?

Please Log in or Create an account to join the conversation.

  • v00d00m4n
More
5 years 1 month ago #13 by v00d00m4n Replied by v00d00m4n on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
Try to think outside of box - if you have no vectors it does not mean you cant assume them!

just a quite example:

this is frame 1 pixel grid 3 by 3

| | |_ |
| |_ | |
|_ | | |

this is frame 2:

| | | |
| | |_ |
| |_ | |

_ - is edge (which we detected in previous step which im not discussing) and - is any other kind of pixels

you can clearly recognise the vector of movement of pixels - they go straight down.

If pixels did not move very far, its not hard detec their movement by spliting whole screen in to greed with some sort of configurable matrix size in which you assume pixels supposed to be same.

So, we got previous frame, we got vector information, we can do sort of Temp AA. Yes its not that precise, mistakes can happen, so this pseudo - temporal AA would not as good as native one, but i think with such per grid cell vector detection we can sort of imitate TAA.

Since its not very fair TAA i suggest to call it PSEUDO-TAA, but just dont say its impossible. Detection of vector should be done with clear edge detection buffers of previous and current frames, we can get this part of code from SMAA debug view and use smaa code for perfect tuning of edge detection and even use depth buffer for more precision, or actually we can improve SMAA shader by adding this PSEUDO TAA step into it and we call it SMAA PSEUDO T2X or SMAA PSEUDO TAA. FXAA could be merged into it as well as alt edge smoothing technique, and we can combine all 3 together in various oders to get best results.
Also, what i think needs to be done - is masking and reconstruction of everything that not considered as edges, with few pixels of margin, to restore pre-TAA sharpness without applying artificial sharpness shader... or we can apply sharpness selectively to those masked zones that are not edges and not few pixels around them, so that sharpness would not ruin AA efforts. I remember thera few shaders in reshade that are separate yet allowed to be used together as few steps of single more complex effect, dont remember the name of it, but we can separate AA and edge masking and put existing sharpening shaders in between.

Anyone want to try to do that?
The following user(s) said Thank You: Sami 1999

Please Log in or Create an account to join the conversation.

  • v00d00m4n
More
5 years 23 hours ago #14 by v00d00m4n Replied by v00d00m4n on topic Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA
Anyone?

Please Log in or Create an account to join the conversation.

We use cookies
We use cookies on our website. Some of them are essential for the operation of the forum. You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.