I want to adjust the amount of frames accumulated and don’t see any console variables pertaining to it. I’d like to adjust my AA to something similar to this paper: https://advances.realtimerendering.com/s2017/DecimaSiggraph2017.pdf
The closest you are looking into would be r.TSR.History.SampleCount, but the minimum is 8 sample per display pixel. The paper you point to only reuse the rendered pixel from previous frame, so that would be as low as 2 samples (current frame + previous frame) per rendering pixel. Thing is TSR reuse previous frame’s TSR history which is agregated accumulation of the renderer pixel in a TAA like exponential average (except the number of samples is actually counted in TSR history as oposed to TAA to speed up the accumulation of rendered details after rejection), so I’m afraid the goal you are wanting to try isn’t expressable in the TSR setting.
I’m attaching you the first 18pages of 5.4’s TSR documentation update (to fit in the file limit) that explains some of this if this can be of any help.
Temporal Super Resolution 5.4 draft v4 1-18.pdf (24.3 MB)
3 Likes
Thank you for the response. Would you mind me asking about TAA then if it’s incompatible with TSR? If it’s not possible there whats the most equivalent setting?
The reason I was interested in this is because we’re working on a large hyper fast-paced FPS shooter (more hectic & fast paced than Fortnite) and currently TSR/TAA both ghost and create some motion blur due to our excessive motion.
At stock values these methods work great for cinematic games but we’re struggling due to our genre of game & game mechanics.
And the way Decima built their TAA for Horizon Zero Dawn seems to be perfect for fast-paced content. If theirs a way to achieve the same or better results via other means I’m all ears, but I’ve spent months reading GDC papers on anti-aliasing from various companies & testing games and that was just the best one for our project. But I’m open to tweaking UE5’s default TAA/TSR if it can deliver the same quality
Im going to read the paper now ~ thank you
Would you mind me asking about TAA then if it’s incompatible with TSR? If it’s not possible there whats the most equivalent setting?
Sorry I should have specified, it’s the same issue with TAA. The closest would be r.TemporalAACurrentFrameWeight, but TAA is also exponential average reprojection, so even setting that cvar at 0.5, you would still have the frames N-2 and before reprojected with a total weight of 0.25, whereas what you are trying to achieve is just have Weight(N) = Weight(N-1) = 0.5
The reason I was interested in this is because we’re working on a large hyper fast-paced FPS shooter (more hectic & fast paced than Fortnite) and currently TSR/TAA both ghost
Have a DumpGPU of the TSR ghosting? Can just limit the dump to TSR and delay the dump by a 3 seconds to have time to repro the ghosting with existing game play logic with:
r.ProfileGPU.Root *TSR*
r.ProfileGPU.Delay 3
and create some motion blur due to our excessive motion.
At stock values these methods work great for cinematic games but we’re struggling due to our genre of game & game mechanics.
Have a look at this PDF’s TSR History section’s FAQ, it explains how to tune TSR history weight under movement for overbluring due to reprojection. TLDR the settings you are looking into are r.TSR.Velocity.WeightClampingSampleCount and r.TSR.Velocity.WeightClampingPixelSpeed. This should also apply to 5.3 TSR although you would be missing the 5.4’s VisualizeTSR tool.
If this can be of your interest, Fortnite sets only these settings in its Config/DefaultEngine.ini:
r.TSR.ShadingRejection.Flickering.Period=2
r.TSR.Velocity.WeightClampingSampleCount=2
And its specilization of the UGameUserSettings also sets r.Tonemapper.Sharpen=0.5 when using TAA, TSR or DLSS.
Thanks for the response however my main follow-up question is what is the value range of the commands you gave me? Some TSR commands in your documentation don’t specify what the full accepted min/max value range is.
I want to know how low or high I can take these settings before its invalid, that will help me configure them. The commands you gave me were theres 3 (but if you have any more that are currently undocumented you’d like to share as well I’m all ears)
r.TSR.Velocity.WeightClampingSampleCount
r.TSR.Velocity.WeightClampingPixelSpeed
r.TSR.ShadingRejection.Flickering.Period
Since I’m going the TSR route now to mitigate this issue theirs still something from the Decima paper I wished worked in Unreal Engine that would be much easier to fix and that is being able to use the engines FXAA at the same time as TAA or TSR, like Decima does.
If I’m going to weaken TSR to reduce motion issues which will cause more aliasing I’d like to also have a post-process AA used alongside it, which will bring back some anti-aliasing without increasing temporal artifacts.
If nessacary I’ll also utilize r.Tonemapper.Sharpen and/or r.MinRoughnessOverride too as apart of clarity & aliasing optimizations
Some TSR commands in your documentation don’t specify what the full accepted min/max value range is.
Thanks for the feedback. Will get this addressed for 5.4 release.
I want to know how low or high I can take these settings before its invalid
Note however there is subjective limits that is different to algorithmic limits. Here are the algorithmic limits for these:
r.TSR.Velocity.WeightClampingSampleCount (between 0 and r.TSR.History.SampleCount)
r.TSR.Velocity.WeightClampingPixelSpeed should be greater or equal to 1
r.TSR.ShadingRejection.Flickering.Period this one is a bit tricky. I’ve attached you 5.4’s documentation about the flickering temporal analysis to better understand it.
Temporal Super Resolution 5.4 draft v4 31-40.pdf (15.6 MB)
Since I’m going the TSR route now to mitigate this issue theirs still something from the Decima paper I wished worked in Unreal Engine that would be much easier to fix and that is being able to use the engines FXAA at the same time as TAA or TSR, like Decima does.
If I’m going to weaken TSR to reduce motion issues which will cause more aliasing I’d like to also have a post-process AA used alongside it, which will bring back some anti-aliasing without increasing temporal artifacts.
We did use FXAA on top of TAA in the Reflection demo by hacking the post processing chain right here https://github.com/EpicGames/UnrealEngine/blob/2b0f20893837df4d5d1f228b1e6a8610d5895e72/Engine/Source/Runtime/Renderer/Private/PostProcess/PostProcessing.cpp#L641 , this was to hide the reprojection aliasing on the spherical heads when they rotate.
Note TSR has a built-in FXAA style algorithm on anti-aliasing quality medium and higher to clean up aliasing when the number of rendered pixel is too low, to hide aliasing. Although there is still a current limitation in TSR at the moment where the aliasing of the velocity buffer used for reprojection can still create aliasing under heavy movement. I’m still working on solving this issue in performant maneur on consoles.
1 Like
Unfortunately that github link you sent is 404’ed (dead) so I’m unable to view it, so I’ll probably have to look elsewhere to figure out how to do that precisely.
You’ve shared some insightful information with me so one of the last things I wanted to ask was that I’ve looked all over online for what these settings do but they don’t seem to be documented like the rest.
r.TSR.ShadingRejection.ExposureOffset
r.TSR.Velocity.Extrapolation
r.TSR.Resurrection
I have a rough idea of what they might do of course, but no certainty. Seems like some new TSR stuff past 5.2 isn’t up-to-date online yet.
r.TSR.ShadingRejection.ExposureOffset
Very complicated one. But you can do in the console the following to get its documentation: r.TSR.ShadingRejection.ExposureOffset ?
r.TSR.Velocity.Extrapolation
An experiment at improving history reprojection accuracy on geometric edge discontinuity, but current algorithm has flaws. It’s remove in 5.3+ in favor better solution with futur reprojection anti-aliasing solution instead.
r.TSR.Resurrection
That is 5.4’s new TSR functionality called out in unreal public roadmap. I’ve attached you 5.4 doc draft section about it.
Temporal Super Resolution 5.4 draft v4 40-44.pdf (14.7 MB)
You just need to setup github access permission for unreal engine: Unreal Engine on GitHub
Hello @xHybred! (and future readers)
Obviously, we are in the same boat. Bit late to noticing this post but in order to allow low frame accumulation, you first need a small jitter sequence to prevent the view from stuttering a bunch. This is why when you lower the AASamples CVAR you can raise the TAA frame weight much higher without encounter insane jittering as fast.
What I mean by jitter sequence is for example the Decima TAA has only 2 positions in the jitter sequence as show here:
UE5 currently locks the jitter pattern to 8 positions as you can see for yourself when TSR is enabled.
You can change the value 8 to 2 which If I’m not mistaken(@Guillaume.Abadie?) will force TSR to utilize the same jitter sequence as TAA with r.TemporalAA.Samples 2 but as you can see, the 2 coordinates are more similar to the SMAATX shown in this paper(page 8, upper left corner).
Replace the code lines here with:
float SamplesX[] = { 0.0f/16.0f, -8.0/16.0f };
float SamplesY[] = { -8.0f/16.0f, 0.0/16.0f };
Put r.TemporalAAFilterSize to 0.09 or you might get a black screen.
To my knowledge, these are the coordinates used in the Decima paper.
Unfortunately, you’ll still need to:
Modify TSR’s or TAA shaders to limit the history to the previous frame
Run SMAA(FXAA is not acceptable on modern hardware, blurry, has serious quality issues) before the frames are blended or spatial upscaling is done.
Implement some form of a 200% buffer so motion isn’t blurred. In the Decima paper, the speak about checkerboard rendering, but in the slides they show how the Decima pattern works well for small scale interpolation to:
And its specilization of the UGameUserSettings also sets r.Tonemapper.Sharpen=0.5 when using TAA, TSR or DLSS.
On compressed video it’s not really noticeable, but sharpening is really ugly on fortnite. I thought it was my screen or something. Sharpness and clarity are not the same. The only reason why the Decima TAA used sharpening was becuase of the FXAA, with something like SMAA which has 99% the same clarity as No AA/MSAA and one past frame+200% spatial buffer, a sharpener shouldn’t be needed and clarity will a a lot further.
TSR holds on to old frames for a crazy about of time which I imagine isn’t very good for performance, with a short frame history, you don’t need to compute so much nor should disocclusion artifacts so extreme.
I’ve actually done tons of testing regarding AA, and the only advantage 1080p with 4xSSAA(4k) vs 1080p with SMAA is thin and specular sampling, which is exactly what the Decima coordinates are meant to tackle.
EDIT: Changing the value from 8 to 2 is only half the job as I just recompiled my source biuld, you also need to delete this if statement and the logic inside.
EDIT: Changed coordinates after analyzing the resolve in HFW, they are now correct & added the filtersize warning.