Thanks again for taking the time!
I try to set shadows, GI, and reflections on low settings in most of the test I do with TSR to rule out any lumen noise.
This is good idea. Another reason is that TSR isn’t the only temporal accumulation of the renderer. Reflections and GI is also only practicable in a performance maneur with temporal accumulation too, but they are as much also subject to ghosting for instance due to some specific on how these temporal accumulation works. this is where the VisualizeTemporalUpscaler show flag in 5.2 should help better diagnose if it is indeed TSR or something else that ghost just by looking wether the ghosting is solely in TSR.Output or also in its inputs!
On every setting including cinematic TSR caused the background to smear on the mannequin’s body. The character looked fuzzy and sharpened 0.3 seconds later.
In the video, it’s 5.2 epic AA setting, same results with >100 or 100 screen percentage at 1080p. I am lowering video resolution so I can attach it to post. But its the same problem and its clear enough. Same results with 30fps cap
Beware of the Edit > Edtior Preferences > Performance > Override game screen percentage settings with editor settings in PIE (or r.Editor.Viewport.OverridePIEScreenPercentage). I’ve had many that got hit with this caveats.
Always worth checking the rendering resolution and there is different way to checks. First, TSR draw events displays rendering resolutions so they are visible in ProfileGPU or DumpGPU or any other third party GPU profiler:
ProfileGPU’s UI:
ProfileGPU log:
DumpGPU:
Also even more convenient in 5.2 the VisualizeTemporalUpscaler shows input and output resolutions.
Now, on the reason TAA or TSR look fuzy even at ScreenPercentage 100 under large movement is: Each frame the grid of pixel being rendered is jittered. That is why in vis SceneColor for instance it is very unstable.
But this means for new areas on screen previously not visibles, the only informations that is the rendered pixel are for the same reason slightly shifted from the output.
Moreover for the upscaling case, different input resolution from output resolution means different distance between input and output pixels that necessarily means there is always be a rendered output pixels where the rendered pixels are not aligned.
This is resampling of the rendering resolution into output resolution that cause this blurs and is a limitation of many (if not all) temporal upscaler. Then adds TSR’s spatial anti-aliaser on top trying to clean the image a bit also adds a bit of blur, as much r.AntiAliasingMethod=1 (FXAA) is a bit blurier than r.AntiAliasingMethod=0 (No AA).
The reason we stick with such anti-aliasing technic is because it is self contained in the renderer. MSAA we support on desktop and mobile renderer doesn’t suffer this issue, but on the otherhand it is straight up impossible to maintain resonably for the deferred renderer due to how invasive MSAA is.
Different games have different needs in terms of anti-aliasing, and there is many games that do indeed prefer alternative anti-aliasing solution like MSAA for image clarity in very fast paced movement throughout environement, and that is ok. But it just come at an engineering and runtime price.
It could be possible for TSR to try to mitigate that pixel realignment blur, but for performance reason, it’s GPU pass doing upscaling, update of history and output is running at display resolution = often the most expensive. Being tied to one pass means only one layer of convolution so a sharpening needs to happen in a pass after. This is where currently tonemapper is great fit, and for the case of r.TSR.History.ScreenPercentage=200 there is that additional TSR resolve pass that does downsscaling from history resolution to output resolution, but that r.TSR.History.ScreenPercentage=200 is expensive too, probably not use on a currernt gen console. A very particular interesting case here however being integrated in TSR that that resolve pass could adaptively sharpen based on much details is accumulated. I’ve filed Unreal Engine Issues and Bug Tracker (UE-183345) (which should become public soon) for you to be able to track progress on that cool idea.
Thanks a lot for your continued feedback! 