Welcome, Guest.
Username: Password: Remember me

TOPIC: Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #1

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIASING) B)
Last Edit: 1 year 4 months ago by francentu3456.
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #2

Have you implemented it or do you want someone to implement it??
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #3

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 administrator has disabled public write access.
The following user(s) said Thank You: 5Alex

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #4

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.
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #5

The silence here makes me think it's impossible. :D
The administrator has disabled public write access.
The following user(s) said Thank You: Exilium

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #6

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 administrator has disabled public write access.
The following user(s) said Thank You: Insomnia, RogueFactor

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 1 year 4 months ago #7

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! [ Click to expand ]


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: 1 year 4 months ago by RogueFactor. Reason: Forgot the URL
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 3 weeks 4 days ago #8

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 :)
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 3 weeks 3 days ago #9

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: 3 weeks 3 days ago by OtisInf.
The administrator has disabled public write access.
The following user(s) said Thank You: canceralp

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 3 weeks 3 days ago #10

I know it's hard to make quality AA in reshade but then in Nvidia Inspector can to enable AA in games?
The administrator has disabled public write access.

Implemented in ReShade TXAA 4x (TEMPORAL ANTI-ALIA 2 weeks 5 days ago #11

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.
The administrator has disabled public write access.