Can TSR affect to how TAA works?
I mean in 5.2 TAA seems to have lot of aliasing compared to 5.1
Here an example: Imgsli . Check the rims or the cars geometry.
I tried to copy the 5.1 TemporalAA.usf to 5.2 to see if maybe some change was made but nope, still aliased.
Wonder if maybe TemporalAA.usf gets some data from TSR? Or maybe there is a bug?
Edit: The thing is, on editor TAA seems to works fine, but on run the project and play around there is like some stuff have none or low AA ¿? .
if it’s only becoming aliased when you stop the camera, increase the sample count.
My project needs photorealism and crisp visuals for gameplay. I use these for when the resolution is set to 1080p.
I find these to be the sweet stop for my project:
r.AntiAliasingQuality=3 (Removes ghosting with framerate’s above 40fps)
r.TemporalAACurrentFrameWeight=0.3 (You will get a much clear image than .004 in trade for some flickering, the flicking can be reduced by 95 percent with the next command)
r.TemporalAASamples=2 (This will keep still objects fairly non-aliased while preventing the the last command from giving you flickering hell)
The default TAA at r.AntiAliasingQuality=3 at 4k with r.Tonemapper.Sharpen .5 looks fine to me in motion clarity at seen in the UE5 reveal.
I highly suggest giving you’re players the option of a more clear regular TAA, no temporal solution(Since there are some who will take noise over a blurry image, make sure to exposed the sharpening to the player), and a custom TAA solution using the variable above.
Not enough studios are giving players the benefit of knowing what they want.
I have the same settings in 5.1.1 and 5.2.
In 5.1.1 TAA is perfect, in 5.2 there is something wrong, is too much aliased.
on editor TAA seems to works fine, but on run the project and play around there is like some stuff have none or low AA
When running the project press ~ button and type r.AntiAliasingQuality=3
Sometimes scalability is off when in play mode. Also make sure your viewport PIE settings are set to manual and dependent on r.ScreenPercentage.
I’m merely troubleshooting here. I test 5.2 TAA and found nothing in comparison except in your comparison shots.
I found the BUG, Scalability settings seems not working as it should.
With Low/Medium/High = good TAA, but on Epic and Cinematic, TAA looks aliased.
I tried setting the screenpercentage to 100 and other and same problem, in case the new changes on TSR(screenpercetage=200 on Epic/Cinematic) affect in some way but nope.
With Low/Medium/High = good TAA, but on Epic and Cinematic, TAA looks aliased.
Interesting I want to see that on my end. Concerning.
EDIT: Define good? Is there ghosting on high still? (High was never good enough for my project)
Im not talking about ghosting, btw i use Epic always.
in 5.2 , using Low/Medium/High i get perfect TAA(when i say perfect TAA, as it should be in 5.1.1), in fact it looks is the same AA in this three modes, cant see a difference. Then, Epic and Cinematic looks like Low scalability now ¿?
Hello!
TAA and TSR implementation remains completly independent to ensure no TSR dev does not regress TAA on last gen consoles in terms of performance or quality.
Anytime I see aliasing only on some object in the scene, this is very often motion vectors like on your 5.1/5.2 comparion image. While 5.1 didn’t have the VisualizeTemporalUpscaler show flags that shows this sort of problem, it did have the VisualizeMotionBlur show flag that should help you quickly verify if this is the issue you are running into.
Well, i found the “problem” is on r.TemporalAA.Quality.
_
Quality of the main Temporal AA pass.
0: Disable input filtering;
1: Enable input filtering;
2: Enable input filtering, enable mobility based anti-ghosting (Default)
_
Looking at BaseScalability.ini, TemporalAA for Epic and Cinematic is set to 2.
That yes, ghosting is decreased, but lowering the AA too much.
Setting 1 for Epic and Cinematic get the good temporalAA im looking.
On 5.1 I see is the same on 5.2, Epic and Cinematic is set to 2, but que quality is very good. So in 5.2, there is something wrong or they changed what r.TemporalAA.Quality=2 does, decreasing the amount of AA to decrease more the ghosting too.
_
I copied the temporalAA.usf from 5.1 to 5.2 but the problem persists, due i saw:
#elif TAA_QUALITY == TAA_QUALITY_HIGH
#define AA_FILTERED 1
#define AA_DYNAMIC_ANTIGHOST 1
That i guess is what TemporalAA.Quality=2 refers, but is the same. So Epic/CInematic scalability on TemporalAA does something different in 5.2 than in 5.1 but cant find what it is. Or maybe in 5.1 the Quality=2 it really did nothing / nor worked due WIP or something and now does what it should do ¿?.
Well, i think i found the issue, was about motion vectors on the cars physics, due they still using the 5.1 plugin instead 5.2. But still no clear if this is the issue.
What i not understand is why with Temporal.Quality 1 does fine but not with 2 ¿?
Also With substepping=false TAA works fine, but if true, TAA goes bad again. Very weird ¿?
WIll wait for the 5.2 plugin release to see if still happens.
Hi @Guillaume.Abadie,
thanks a lot for clarifying my cvar settings a while ago. I have another question.
I am using a scene capture component 2D object and in the settings you can enable Temporal AA instead of FXAA.
Can you say if this setting also works for TSR if enabled?
Hi!
Yes enabling the TemporalAA showflag (still named this way for legacy reason) is important on the scene capture. Then you also need set two other settings on your scene capture:
With all of this set up you should be good to go, but always worth double checking with ProfileGPU or DumpGPU that TSR is actuall running your scene capture. Note you can set the profiling event name of your scene capture to more easily identify it in ProfileGPU, DumpGPU or other third party GPU debugging tool like renderdoc or pix.
Here is an example with ProfileGPU:
I just want to say I’ve been broadly very happy with the results from TSR, and I want to use it but I’ve had to disable it specifically because of two issues I’ve encountered with how TSR behaves compared to TAA when using Lumen and Nanite.
It’s frustrating because I don’t think TSR is responsible for either of these behaviors. The holes in Nanite meshes seems to be intrinsic to how Nanite works, they’re just less noticeable with TAA. Lumen’s problem specifically seems to be caused by its own screen traces, which for some inexplicable reason behave differently when TSR is used.
I’ve tried reporting these as bugs to no avail, I’m not even sure what the intended behavior is supposed to be.
I’d really like to know how you are managing these problems at Epic, if at all… Because so far the best solution I have come up with is to simply go back to using TAA.
This seems really promising. I’m currently using Unreal 5.1 and this option doesn’t appear for me.
Historically, I’ve noticed a lot of ghosting effects when I’m using an animated model with a high furcard density and SceneCaptures. It looks perfectly fine in the viewport, which makes me think it’s an issue with SceneCaptures.
TAA also has smudging in the captures but only if multiple captures are happening at once.
I’m not entirely sure how best to debug this. Do you think updating to UE5.2 and using these flags might help? I’m not using any WPO materials to my knowledge, and velocity seems to be writing properly.
Thanks much!
Dense Nanite meshes have pixel height holes in them that are visible with TSR, but partly mitigated by using TAA.
This issues is less noticeable with TAA becauses it’s a bit like a details that TAA eats away.
Lumen’s screen traces pick up translucent emissive surfaces when using TSR , but not when using TAA.
Thanks for bringing this to my attention, I was not made aware of this issue before. I’ve hunt down the bug to this line of code: https://github.com/EpicGames/UnrealEngine/blob/f960f40f79fec98bd687c1b3b2ec76222be85c70/Engine/Source/Runtime/Renderer/Private/PostProcess/TemporalSuperResolution.cpp#L2201 where TSR extracts its output into View.ViewState->PrevFrameViewInfo.CustomSSRInput that then gets used next frame by lumen screen space tracing instead of View.ViewState->PrevFrameViewInfo.ScreenSpaceRayTracingInput that notably avoids highlight leaking between in the SSGI trace. The correct thing to do to still have legacy SSR working correctly with TSR is to instead output in View.ViewState->PrevFrameViewInfo.TemporalAAHistory with these lines:
// Extract the output for next frame SSR so that separate translucency shows up in SSR.
{
// Output in TemporalAAHistory and not CustomSSR so Lumen can pick up ScreenSpaceRayTracingInput in priority to ensure consistent behavior between TAA and TSR.
GraphBuilder.QueueTextureExtraction(
SceneColorOutputTexture, &View.ViewState->PrevFrameViewInfo.TemporalAAHistory.RT[0]);
View.ViewState->PrevFrameViewInfo.TemporalAAHistory.ViewportRect = OutputRect;
View.ViewState->PrevFrameViewInfo.TemporalAAHistory.ReferenceBufferSize = OutputExtent;
}
I have the fix pending for review for 5.3.
It looks perfectly fine in the viewport, which makes me think it’s an issue with SceneCaptures.
Smells like motion vectors yet again sadly. We found not that long ago that having multiple FSceneViewFamily per frames could lead to major motion vector bug on skeletal meshes. This fix could possibly fix what you are running into if I understand correctly: https://github.com/EpicGames/UnrealEngine/commit/e37bae26cec8a5287aa508941ec06a92b689f06e
I’m not entirely sure how best to debug this. Do you think updating to UE5.2 and using these flags might help? I’m not using any WPO materials to my knowledge, and velocity seems to be writing properly.
DumpGPU ( GPUDump Viewer Tool in Unreal Engine | Unreal Engine 5.0 Documentation ) or other third party GPU frame debugging tools like pix ( Download - PIX on Windows ) or renderdoc ( https://renderdoc.org/ ) are extensive tools that allows to have better understanding in what is happening in internals of the renderer. But in 5.1 for specifically the description of your bug, you might also be able to get the VisualizeMotionBlur show flag to should show very incosnsitent motions between your scene capture and view.
WIll be possible use TSR+FXAA? Like reducing a bit TSR effect for less ghosting and use FXAA to fix that AA gap. Also maybe can improve perfomance and reduce blurring.
Will be great have an option for that in 5.3 . Also for TAA+FXAA or MSAA+FXAA.
Thank you for your response! Unfortunately, now the entire model has smudging issues in Unreal 5.2 (I started an upgrade branch) in the viewport with any form of movement. There is one area that used to be consistently smudged and no longer is, which is a plus, but the overall quality has degraded.
This makes me think velocity needs to write at a different time than what it is currently perhaps? I currently have it writing during the base pass.
EDIT: I noticed that the “Per Bone Motion Blur” was turned off for certain models. Turning that on made the problematic models behave properly in the viewport again. I’ll continue testing this change and follow up later.
EDIT (again): So SceneCaptures that are not with a Capture Source of Final Color typically do not have the smudging/ghosting effects. Final Color has a lot of smudging, which is a shame because it appears correctly in the viewport. How do you turn on the VisualizeMotionBlur for a simple scenecapture2d? I don’t see the flag for doing so.
While looking through some of the dumpgpu output, I do see some of the velocity passes seemingly split in data (one has a moving model fully split down the middle). Unsure if that’s just a quirk of the command output or a legitimate issue.
Hey @Guillaume.Abadie,
Is there any way to get access to the Z buffer values inside the TSRUpdateHistory.usf like in TemporalAA.usf ?
Hello @Guillaume.Abadie 
do you by any chance have an idea about how to reduce TSR ghosting and smearing artifacts while using masked materials, f.e. for flipbooks? Most tips and tricks are for flipbooks/sprites, that use a translucent material. But since those are not working that well with some light effects, like, they (still) can´t cast shadows, i tend to use masked materials.
And while the ghosting and smearing is not as bad as with TAA (there it´s a real nightmare -.-´), it´s still noticeable in several cases.
Some projectils leave a trail of a rough area behind, until it gets smoothed out, other times like during character walking (or in any case, where the flipbook switches to a new sprite to play an animation) you have noticeable artifacts around that flipbook/sprite.
One video for projectiles (youtube compression seems to hide it a little bit, but its still noticeable):
Another one where artifacts are quite visible around the character:
Edit: here a multi-directional test-char amde with masked flipbooks, where it becomes really visible. The shadows from those balls and the balls themselves become quite a mess during moving and rotation:
Nop. But you can customise the engine to do whatever experiment you may want. The file to modify that selectively setups FXAA or TSR is this one: https://github.com/EpicGames/UnrealEngine/blob/ue5-main/Engine/Source/Runtime/Renderer/Private/PostProcess/PostProcessing.cpp
Is there any way to get access to the Z buffer values inside the TSRUpdateHistory.usf like in TemporalAA.usf ?
No and there is no need for it in the current algorithms that works with parallax mask instead generated the DecimateHistory pass. This saves memory bandwidth as this only 1byte per rendering pixel instead of 4byte which is important to have in mind to save memory bandwidth available for the previous frame’s history reprojection in the UpdateHistory pass.
But nothing prevents you to customise FTSRUpdateHistoryCS::FParameters to add a SHADER_PARAMETER_RDG_TEXTURE() for the depht buffer for your need.
Some projectils leave a trail of a rough area behind, until it gets smoothed out, other times like during character walking (or in any case, where the flipbook switches to a new sprite to play an animation) you have noticeable artifacts around that flipbook/sprite.
Rough area behind is due to completly discarding the details and needing to reaccumulate. This is where the idea of the TSR history resurection explained earlier should help ( TSR feedback thread - #3 by Guillaume.Abadie )
Another one where artifacts are quite visible around the character:
You are talking about the motion blur arround the character? I don’t see anything obviously wrong from TSR on this.
Edit: here a multi-directional test-char amde with masked flipbooks, where it becomes really visible. The shadows from those balls and the balls themselves become quite a mess during moving and rotation:
Yeah fast moving shadows is known problem ( Unreal Engine Issues and Bug Tracker (UE-182858) ), the r.TSR.ShadingRejection.Flickering heuristic used on high and Epic anti-aliasing scalability thinks it’s a pixel becoming unstable like moire pattern and try to stabilize it a bit. You should be able to lower r.TSR.ShadingRejection.Flickering.Period in your Project’s Config/DefaultEngine.ini to lower it (or even disable completly as I doubt your content will have a lot of moire generated patterns).
So SceneCaptures that are not with a Capture Source of Final Color typically do not have the smudging/ghosting effects.
That might because Final Color is the one that has the processing chain where TAA/TSR or otehr third party temporal upscalers are.
While looking through some of the dumpgpu output, I do see some of the velocity passes seemingly split in data (one has a moving model fully split down the middle). Unsure if that’s just a quirk of the command output or a legitimate issue.
That sounds like an interesting find.