Improvements to TAA#113043
Conversation
mrjustaguy
force-pushed
the
TAA-Patch
branch
2 times, most recently
from
5b04ebb to
d82d1bc
Compare
mrjustaguy
force-pushed
the
TAA-Patch
branch
2 times, most recently
from
2972d67 to
d5998ec
Compare
|
Hi, I decided to test this because TAA has given me issues in the past, especially with detailed foliage. Heres some videos showing the difference compared to the current version of Godot. Here is this pull request TAA_test3.mp4Here is the current stable release TAA_test4.mp4Video encoding might make it look worse. Detailed foliage still gets a bit blurry but I notice overall less ghosting, particularly when trees pass over other trees in the background. I dont notice any artifacts with the sky now. |
|
Most of the ghosting is likely due to #112196 and not this, though some edge stability is due to the anti-flicker algorithm. The Sky is totally due to this PR. I have considered changing the clipping to a 5 sample + instead of 9 sample box, which should reduce the blur a little, but it also weakens some of the hidden benefits of TAA (such as being able to use lower soft shadow sample counts and still get a smooth looking result) If the Textures are an issue, playing around with mipmap bias could improve things Edit: After some further testing it seems the new Anti-Flicker algorithm is producing more blur then reducing Flicker in typical scenarios, especially visible when reducing the texture mipmap bias to the lowest value, with and without the Anti Flicker algorithm, so I think it's safe to actually totally ditch Anti Flickering mechanism, whatever I come up with just causes more problems, and the old one was causing major issues (as extremely clearly shown in the first 2 videos of this PR) |
Could the samples be configured in the project settings so the user can choose what is better for they project? |
Yes, however I don't have the expertise required to do so, and considering the types of things that are exposed as settings in Godot, this falls very clearly into the Category of "Don't Expose" as there are plenty of other knobs that could be exposed to the user just with TAA alone, but aren't by choice. (Like how Aggressive the Clipping is, for stability and ghosting vs instability and responsiveness tradeoff - see #111381 if you're into discussion regarding this topic) Edit: Tested the 5 sample clipping, and in my test scenes it makes things a little sharper, without seemingly negatively affecting the stability overall, just negatively affecting the soft shadow blurring a little (expected, and should likely reduce any potential shadow ghosts so that's a win IMO) As Such I'll switch to the 5 sample clipping, but I'll leave the 9 sample code in should somebody wish to use that |
mrjustaguy
force-pushed
the
TAA-Patch
branch
2 times, most recently
from
a254100 to
a6109a9
Compare
|
@KawaiiPrincess Please Retest once this finishes building to see if the blurring has been reduced, and if there are any new issues. I've Removed the Anti-Flicker, and Turned to the Stricter 5 sample Clipping |
|
This PR makes the flickering absolutely worse. |
|
This is sadly expected, but that's the cost of making it more responsive (less ghosts) and fixing issues caused by anti-flickering algorithms be they old (which only reduced flicker on static shots and absolutely borked edges) or new (which from the few methods I tried either resulted in similar issues to the old one, or caused massive ghosting, or just plain didn't do all that much to reduce flicker) But hey, this is 1 of 3 TAA methods, (TAA, FSR 2, FSR3 incoming) with each having their own trade-offs. IMO before these changes TAA was the clear loser considering the numerous serious issues it had, with the single benefit being a little more performance. |
|
TAA is not working with MSAA and shows a lot of flickery with high frequency details, compared to master. Is it a good idea to remove the anti-flicker? |
|
MSAA is a regression from another PR in master, and the anti flicker only helps with flickering on static elements, it'll actually Cause Flicker and the Issues explained in the OP Look at the edges of the Crystals in motion in this example from my Game Asset, this is purely the Anti-Flicker algorithm causing problems, and that's just one of the problems the thing is causing. Master unknown_2025.11.25-18.01_1.mp4PR unknown_2025.11.25-18.03.mp4No AA for reference, for what kind of aliasing it's dealing with 
It's also responsible for erasing bright Bullets in the distance and stuff as they get considered "flicker", which is from a gameplay perspective IMO Absolutely, Completely Unacceptable. So yeah I'd say it's a good idea to remove it, when it's causing more trouble then it's handling. In the future I'd like to figure out a way to get a much more robust anti-flicker algorithm in place that doesn't create all these issues so clearly present. |
|
I checked and TAA + MSAA in master is working |
|
yes #113130 was merged 4 hours ago fixing it, so downloading the current artifact for this PR also works with MSAA |
|
Newest version: TAA_test5.mp4No Anti Aliasing TAA_test6.mp4Looks good to me with little ghosting now. There's a little flickering around fine details but I can see some of that even with the version with the anti flicker version anyways, so that can be fixed later. I think this is a major improvement to TAA. Edit: that slight flickering is also present in FSR2, so it's probably unrelated to any changes here. |
BTW, just came to my mind, what's the flickering state of FSR 2.3 and FSR 3.1? (see #111631) |
|
Ok just a Heads-up I'm working on yet another approach to getting an Anti-Flicker Algorithm. It's an extremely stupid approach so don't get your hopes up, and it'll probably need a fair bit of testing and likely a solid bit of tuning to be usable if it works out. |
|
Um, I don't know if anybody will understand the reference but... I just successfully played the parts of both the Asgard and Carter and sent my O'neill and I blew up the unknown_2025.11.26-01.01.mp4I've run all the test scenes and it doesn't seem to be causing Any issues in any of them, and played my game with it for 15 minutes without being able to find any issues, all the while it's been doing it's job really well. |
mrjustaguy
force-pushed
the
TAA-Patch
branch
from
a6109a9 to
e056021
Compare
|
I don't know I'm first focusing on getting the correctness out of the way. Though memory usage will drop a tad (once cleaned up), Last Velocity Buffer is no longer required. Edit: Master vs Current PR both result in identical TAA cost according to Godot's Visual Profiler I've updated the PR page to the current status, changing anything that became irrelevant or substantially different |
|
@KawaiiPrincess I may have figured out why the Rocks lose AA, watching at 0.25 speed at full screen, I believe this is happening due to Disocclusion setting the blend factor to 1 (rejecting history totally) and the old anti flicker was reverting that change stabilizing the result, which the new anti flicker method didn't do and no anti flicker method also obviously didn't do. Please retest with the new Disocclusion changes made and see if there has been an improvement. Also if you can build Godot, I suggest you go on master to this section of taa_resolve and just before return add This is what the current section looks like on this PR This will help confirm the theory |
|
Hmm, could you post some images comparing the current state of the PR with master (both TAA on/off)? I just looked at some of the images and somehow got the impression that the AA along the edges of geometry has gotten a lot worse. For example look at the lower right section of the image you posted earlier, you can clearly see aliasing between the spaceship and background and the spaceship and emissive light: 
|
I've just noticed however there's some Chromatic issues going on with the new method. Also all 3 images have SMAA enabled as only that was helping with Bright edges (master and PR in it's many forms)
I'm not sure if this is something that can be resolved, and this behavior is present in all disocclusion calculation methods, it just depends on the settings used and the scenario. I can make the disocclusion more relaxed, to mitigate this, but I'd have to go stricter on the new history clipping to mitigate the ghosts, which now that I look at the pics better, seem to actually be the chromatic issue ghosting, and I may have an idea for that |
I've brought back the clip_aabb method and plugged in center sample instead of the avg color, with no other changes to the current state of the PR and It seems to have helped, though only partially as now the Edges have gone to hell, with some types of motion, just like what the Old anti flickering caused 🙄 |
|
OK I've figured out what's going on with the chromatic issue. It's being caused by my projectile lights and they seem to only be visible in screen shots, as I've been unable to see a single instance live, possibly being masked by the display or the eyes, and also possibly by the fact they're extremely short lived effects (at 60fps) As such I've taken no action given the two things I tried (restoring clip_aabb and separating chroma and intensity calculations) both resulted in clearly observable issues of their own. |
|
I've updated the OP with the current PR result |
|
I've just removed the as of recently unused last velocity buffer, improving TAA performance (according to Godot's Visual Profiler) from a consistent 1.03-1.05ms to a consistent 0.93-0.94ms at 1440p on an RX 6600 |
|
Tested Master vs current State of the PR for performance differences just now. Taken at 1440p on an RX 6600 with Godot's Visual Profiler That's quite a solid, consistent improvement. I didn't expect to see a measurable performance uplift from master going into this. |
|
I've pushed new changes, all Edge problems I've ever seen with Godot's TAA have been resolved, however I had to revert the Background Patch, as it broke Edges for anything that was rendering on the background, and the only solution would be to properly generate Motion Vectors for the Background, For which I don't posses the required expertise. I'll update the OP at a later time, when I also fully clean up all the dead code and all. The edges were fixed by using the shortest 3x3 velocity (that isn't with 0 depth aka background) as otherwise the velocity would be asking for history that isn't relevant for the aliased edge. This was also causing Shrinking and Expanding Edges as well as outright removal of Antialiasing, depending on the case. |
mrjustaguy
force-pushed
the
TAA-Patch
branch
2 times, most recently
from
addd34f to
1bf4cbe
Compare
|
I'm dropping the Edge Fix as while it did fix objects moving in tandem with the camera, it didn't fix other objects, and may introduce more issues, better to just let SMAA handle the edges |
Remove Tonemap Step to maintain glow better Change History Clipping to prevent pixelization from appearing Change Disocclusion to make it more responsive and reduce Ghosting with the new History Clipping Remove Anti-Flicker as it was causing issues, like dark shadow ghosts, Thin bright objects being incorrectly darkened and vice-versa Added fast convergence for Backgrounds to reduce Background Smearing Move History Clipping to Resolve
mrjustaguy
force-pushed
the
TAA-Patch
branch
from
1bf4cbe to
d625b4a
Compare
|
I've moved History Clipping to clip the Resolve instead. This stabilized the edges a bit, and I haven't noticed any major regressions. |
|
I didn't know if I should open a new branch or just help in this branch, so I decided to help this branch to make the improvement even better. All I did is change the jitter positions to a total of 2 (creating the flip-quad grid) in renderer_scene_cull.cpp and the blend_factor to FPC_2 in taa_resolve.glsl. This is with the modified jitter positions + increased blend factor: The biggest problem though is the ghosting that stays the same no matter the blend factor. This is the current implementation: This is with the modified jitter positions + increased blend factor: This is my implementation I was working on that was just a fork of the previous taa implementation but with the modified jitter positions + increased blend factor as discussed previously: Let me know if I should work on a different fork or if this would be of interest for the current merge! |
|
How does Edge stability in motion behave with just the change (without my changes and with would also be useful info) you can test #68343 MRP as it shows the sphere being quite awful with TAA (not so with FSR, do note by default FSR 1 is used at 0.6 scale in the MRP so for FSR 2 testing you need to go native on both for a more apples to apples comparison) Also test out #111631 (comment) for general stability and AA comparisons As far as the ghosting goes, with the new one there are two things that may be helping cause it, the change of clamping instead of variance clipping (which I found out seems to be what FSR 2 is doing) and the latter is the fact I moved the step to the resolve instead of the history, as it improved on the edge results a fair bit (though still quite lousy compared to every other TAA I've seen) I am not opposed to this being merged with my work (or superseding it), though a part of me is unsure if clumping everything in one go or splitting it up into a bunch of smaller PRs is the way to go, as this PR did get somewhat bloated, but also to be fair TAA is prone to being a Whack-a-Mole game which means it makes splitting up make very little sense, as a fix in one scenario can lead to issues with a fix for another thing when combined, and I've had to test hundreds of combinations to arrive at the current results just due to that fact. I do think using only 2 instead of 16 jitter points could be quite good when combined with SMAA, and I do see a possibility of new tricks being available with that change, however I do fear the AA quality could suffer for static scenes (hence the possible SMAA requirement) Do also note, with 2 points the Background problem solution is scrapped (in a good way) and thus the depth can be scrapped adding some performance wins. Also, just an FYI as an additional note, over the next 2 weeks I may not be very responsive Aand another note, with 2 jitter points the clipping could be done between two pixels, which could SIGNIFICANTLY reduce any unwanted ghosting, while preserving AA, as you got the input pixel, and the up/down pixel depending on the period of the jitter you are in, which has fantastic potential I think, totally worth an investigation |
|
I tested the sphere scene, the FSR scene and a edge stability scene I made myself (I can definitely change it if necessary). Here are the results: This is your current implementation on your latest published build of TAA-Patch. (Sphere test) This is my implementation on the master branch of Godot. (Sphere test) This is both implementations combined. (Sphere test) This is your current implementation on your latest published build of TAA-Patch. (FSR test) This is my implementation on the master branch of Godot. (FSR test) This is both implementations combined. (FSR test) This is your current implementation on your latest published build of TAA-Patch. (Edge stability test) This is my implementation on the master branch of Godot. (Edge stability test) This is both implementations combined. (Edge stability test) My implementation and the combined one are both very similar tbh. I can't really see a difference. I don't know if I pulled your implementation correctly, but it looks like the sphere test is still a big issue. |
|
Well I think you should make this PR (without my part) and for me to redo and adapt any of the ideas from this work to your work after the fact. I do notice however in the tests that it is aliasing more, but that is expected, however I do believe there's a lot of ghosting problems that this can help resolve as you just need to clip between 2 instead of 9 pixels, and I'd guess some post procress AA like SMAA can be used to help AA further Anyhow as such I'm drafting this for now. |
|
I just created an new PR with my 2 jitter position implementation. #114644 |
|
I am abandoning my TAA work, I have resolved the problem that I went to TAA to resolve in the first place with a Temporally Stable, non Temporal (aka Spatial) Filter I made, paired with SMAA which works better (no ghosting and jittering or invalid motion vectors and such) For reference what I'm talking about No Filter case 1 
Filter case 1 
No Filter case 2 
Filter case 2 
No Filter case 3 
Filter case 3 
Feel free to salvage anything useful from this PR. |
9 participants
Directly superseding #113003 as the solution to the Edge
Resolves Issue with Thin Bright Moving Objects on a dark background becoming very Dark and vice-versa
Maintain Glow better
Mostly Resolves #67332
Removed The Anti-Flicker Algorithm
Was Causing Edge instability Problems, and was not maintaining intended thin moving objects well on a high contrast background objects (say bright bullet flying past a dark background, which FSR would maintain fine) and even outright light ghosting, and alternative anti flicker algorithms were ineffective or caused blur
Add Background Fast Background Convergence
Resolves issue with Background Stars dimming when Rotating Camera (likely due to no valid Motion Vectors provided)
Note - The following are Images of a Video Playback of the Same Motion, because the Videos are Recorded at a Very High Bitrate and are colossal, otherwise they Completely fall apart to completely Compression Artifacts (and even with 100 Mb/s, the max Radeon ReLive supports suffers from significant Compression issues visible in the pictures provided) so these are for demonstration of a change, as this pathological case you need to see it live.
Master
PR
Changed Disocclusion and History Clipping
Resolved randomly appearing Low Res appearance caused by the Old History Clipping.
New Algorithm (It's safe to Ignore the slight Chroma issue, that's Bullet and Bullet Light ghosts, both of which are really bright and not actually visible live, likely due to some combination of Display and Eyes covering and it being an extremely short lived effect)
Master with Variance Clipping in some instances (doesn't always occur)
The Disocclusion was changed to use both velocities from the current frame velocities, with the current sample and the reprojected sample velocities, instead of current sample velocity and reprojected last frame velocity. This improves performance a little and prevents instances where Disocclusion was clearing the whole screen when changing movement
This was required with the new Clipping to minimize ghosting properly, as well as changing the Disocclusion scale and threshold which were set to 1 and 0 respectively (so removed) as this seems to have resulted in the best results in testing when using the new disocclusion
Remove The Tonemapping Step
The Tonemapping Step caused issues with Glow Stability, and didn't actually change much else
Master
unknown_2025.11.24-01.10.mp4
PR Without Tonemapping Step
unknown_2025.11.24-01.06.mp4
PR With Tonemapping Step
unknown_2025.11.24-01.15.mp4