| r.TSR.AsyncCompute |
Controls how TSR run on async compute. Some TSR passes can overlap with previous passes.0: Disabled (default);1: Run on async compute only passes that are completly independent from any intermediary resource of this frame, namely ClearPrevTextures and ForwardScatterDepth passes;2: Run on async compute only passes that are completly independent or only dependent on the depth and velocity buffer which can overlap for instance with translucency or DOF. Any passes on critical path remains on the graphics queue;3: Run all passes on async compute; |
| r.TSR.Debug.ArraySize |
Size of array for the TSR.Debug.* RDG textures |
| r.TSR.History.R11G11B10 |
Select the bitdepth of the history. r.TSR.History.R11G11B10=1 Saves memory bandwidth that is of particular interest of the TSR's UpdateHistory's runtime performance by saving memory both at previous frame's history reprojection and write out of the output and new history.This optimisation is unsupported with r.PostProcessing.PropagateAlpha=1.Please also not that increasing r.TSR.History.ScreenPercentage=200 adds 2 additional implicit encoding bits in the history compared to the TSR.Output's bitdepth thanks to the downscaling pass from TSR history resolution to TSR output resolution. |
| r.TSR.History.SampleCount |
Maximum number sample for each output pixel in the history. Higher values means more stability on highlights on static images, but may introduce additional ghosting on firefliers style of VFX. Minimum value supported is 8.0 as TSR was in 5.0 and 5.1. Maximum value possible due to the encoding of the TSR.History.Metadata is 32.0. Defaults to 16.0. |
| r.TSR.History.ScreenPercentage |
Resolution multiplier of the history of TSR based of output resolution. While increasing the resolution adds runtime cost to TSR, it allows to maintain a better sharpness and stability of the details stored in history through out the reprojection.Setting to 200 brings on a very particular property relying on NyQuist-Shannon sampling theorem that establishes a sufficient condition for the sample rate of the accumulated details in the history. As a result only values between 100 and 200 are supported.It is controlled by default in the anti-aliasing scalability group set to 200 on Epic and Cinematic, 100 otherwise. |
| r.TSR.History.SeparateTranslucency |
Whether separate translucency should be accumulated separatly. |
| r.TSR.History.UpdateQuality |
Selects shader permutation of the quality of the update of the history in the TSR HistoryUpdate pass currently driven by the sg.AntiAliasingQuality scalability group. For further details about what each offers, you are invited to look at DIM_UPDATE_QUALITY in TSRUpdateHistory.usf and customise to your need. |
| r.TSR.RejectionAntiAliasingQuality |
Controls the quality of TSR's built-in spatial anti-aliasing technology when the history needs to be rejected. While this may not be critical when the rendering resolution is not much lowered than display resolution, this technic however becomes essential to hide lower rendering resolution rendering because of two reasons:- the screen space size of aliasing is inverse proportional to rendering resolution;- rendering at lower resolution means need more frame to reach at least 1 rendered pixel per display pixel.By default, it is only disabled by default in the low anti-aliasing scalability group. |
| r.TSR.ShadingRejection.ExposureOffset |
The shading rejection needs to have a representative idea how bright a linear color pixel ends up displayed to the user. And the shading rejection detect if a color become to changed to be visible in the back buffer by comparing to MeasureBackbufferLDRQuantizationError().It is important to have TSR's MeasureBackbufferLDRQuantizationError() ends up distributed uniformly across the range of color intensity or it could otherwise disregard some subtle VFX causing ghostin.This controls adjusts the exposure of the linear color space solely in the TSR's rejection heuristic, such that higher value lifts the shadows's LDR intensity, meaning MeasureBackbufferLDRQuantizationError() is decreased in these shadows and increased in the highlights, control directly.The best TSR internal buffer to verify this is TSR.Moire.Luma but must be verified in DumpGPU with the RGB Linear[0;1] source color space against the Tonemaper's output in sRGB source color space. |
| r.TSR.ShadingRejection.Flickering.AdjustToFrameRate |
Whether r.TSR.ShadingRejection.Flickering.Period settings should adjust to frame rate when below r.TSR.ShadingRejection.Flickering.FrameRateCap. Please read r.TSR.ShadingRejection.Flickering's help for further details. (Enabled by default). |
| r.TSR.ShadingRejection.Flickering |
Instability in TSR output 99% of the time coming from instability of the shading rejection, for different reasons:- One first source of instability is most famously moire pattern between structured geometry and the rendering pixel grid changing every frame due to the offset of the jittering pixel grid offset;- Another source of instability can happen on extrem geometric complexity due to temporal history's chicken-and-egg problem that can not be overcome by other mechanisms in place in TSR's RejectHistory pass: how can the history be identical to rendered frame if the amount of details you have in the rendered frame is not in history? how can the history accumulate details if the history is too different from the rendered frame?When enabled, this heuristic monitor how the luminance of the scene right before any translucency drawing stored in the TSR.Moire.Luma resource how it involves over successive frames. And if it is detected to constantly flicker regularily above a certain threshold defined with this r.TSR.ShadingRejection.Flickering.* cvars, the heuristic attempts to stabilize the image by letting ghost within luminance boundary tied to the amplititude of flickering.One particular caveat of this heuristic is that any opaque geometry with incorrect motion vector can make a pixel look identically flickery quicking this heuristic in and leaving undesired ghosting effects on the said geometry. When that happens, it is highly encourage to verify the motion vector through the VisualizeMotionBlur show flag and how these motion vectors are able to reproject previous frame with the VisualizeReprojection show flag.The variable to countrol the frame frequency at which a pixel is considered flickery and needs to be stabilized with this heuristic is defined with the r.TSR.ShadingRejection.Flickering.Period in frames. For instance, a value r.TSR.ShadingRejection.Flickering.Period=3, it means any pixel that have its luminance changing of variation every more often than every frames is considered flickering.However another caveats on this boundary between flickering pixel versus animated pixel is that: flickering happens regardless of frame rate, whereas a visual effects that are/should be based on time and are therefore independent of the frame rate. This mean that a visual effect that looks smooth at 60hz might appear to 'flicker' at lower frame rates, like 24hz for instance.To make sure a visual effect authored by an artists doesn't start to ghost of frame rate, r.TSR.ShadingRejection.Flickering.AdjustToFrameRate is enabled by default such that this frame frequency boundary is automatically when the frame rate drops below a refresh rate below r.TSR.ShadingRejection.Flickering.FrameRateCap.While r.TSR.ShadingRejection.Flickering is controled based of scalability settings turn on/off this heuristic on lower/high-end GPU the other r.TSR.ShadingRejection.Flickering.* can be set orthogonally in the Project's DefaultEngine.ini for a consistent behavior across all platforms.It is enabled by default in the anti-aliasing scalability group High, Epic and Cinematic. |
| r.TSR.ShadingRejection.Flickering.FrameRateCap |
Framerate cap in hertz at which point there is automatic adjustment of r.TSR.ShadingRejection.Flickering.Period when the rendering frame rate is lower. Please read r.TSR.ShadingRejection.Flickering's help for further details. (Default to 60hz) |
| r.TSR.ShadingRejection.Flickering.MaxParallaxVelocity |
Some material might for instance might do something like parallax occlusion mapping such as CitySample's buildings' window's interiors. This often can not render accurately a motion vector of this fake interior geometry and therefore make the heuristic believe it is in fact flickering.This variable define the parallax velocity in 1080p pixel at frame rate defined by r.TSR.ShadingRejection.Flickering.FrameRateCap at which point the heuristic should be disabled to not ghost.(Default to 10 pixels 1080p). |
| r.TSR.ShadingRejection.Flickering.Period |
Periode in frames in which luma oscilations at equal or greater frequency is considered flickering and should ghost to stabilize the image Please read r.TSR.ShadingRejection.Flickering's help for further details. (Default to 3 frames). |
| r.TSR.ShadingRejection.SampleCount |
Maximum number of sample in each output pixel of the history after total shading rejection.Lower values means higher clarity of the image after shading rejection of the history, but at the trade of higher instability of the pixel on following frames accumulating new details which can be distracting to the human eye (Defaults to 2.0). |
| r.TSR.ShadingRejection.TileOverscan |
The shading rejection run a network of convolutions on the GPU all in single 16x16 without roundtrip to main memory. However chaining many convlutions in this tiles means that some convolutions on the edge arround are becoming corrupted and therefor need to overlap the tile by couple of padding to hide it. This controls is controled by default in the anti-aliasing scalability settings. |
| r.TSR.Subpixel.DepthMaxAge |
Maximum age in frames of subpixel's depth kept in history for their self reprojection (default to 3 frames). |
| r.TSR.Subpixel.IncludeMovingDepth |
Whether the depth of moving subpixel detail should also be included in the subpixel depth history for their reprojection. This is a really bad idea to turn this on because it is impossible how a moving object's velocity involves overtime when it's only occasionally drawing its velocity. (disabled by default). |
| r.TSR.Subpixel.Method |
One particular challenge of Nanite amount of details is that sometimes these details can be thiner than a rendering pixel in which case they only render in some frames. When that happens, it means neither depth or velocity buffer to be able to reproject them. This is for instance visible with the vis SceneDepthZ command.This settings control the method to reproject and/or discard the subpixel details.0: disable subpixel details accumulation in history which means all this these subpixel features may ghost;2: accumulate subpixel details' closest depth to be able to reproject them even when not drawing in depth/velocity buffer which works great for static geometry but not so much for any moving geometry (default) |
| r.TSR.Velocity.WeightClampingPixelSpeed |
Defines the output pixel velocity at which the the high frequencies of the history get's their contributing weight clamped. It's basically to lerp the effect of r.TSR.Velocity.WeightClampingSampleCount when the pixel velocity get smaller than r.TSR.Velocity.WeightClampingPixelSpeed. (Default = 1.0f). |
| r.TSR.Velocity.WeightClampingSampleCount |
Number of sample to count to in history pixel to clamp history to when output pixel velocity reach r.TSR.Velocity.WeightClampingPixelSpeed. Higher value means higher stability on movement, but at the expense of additional blur due to successive convolution of each history reprojection.It is possible to visualize the number of sample in TSR history with the console command vis TSR.History.Metadata.Please note this clamp the sample count in history pixel, not output pixel, and therefore lower values are by designed less noticeable with higher r.TSR.History.ScreenPercentage. This is done so such that increasing r.TSR.History.ScreenPercentage uniterally & automatically give more temporal stability and maintaining sharpness of the details reprojection at the expense of that extra runtime cost regardless of this setting.A story telling game might preferer to keep this 4.0 for a 'cinematic look' whereas a competitive game like Fortnite would preferer to lower that to 2.0. (Default = 4.0f). |
| r.TSR.WaveOps |
Whether to use wave ops in the shading rejection heuristics to speeds up convolutions.The shading rejection heuristic optimisation can be particularily hard for shader compiler and hit bug in them causing corruption/quality loss.Note this optimisation is currently disabled on SPIRV platforms (mainly Vulkan and Metal) due to 5min+ compilation times in SPIRV backend of DXC which is not great for editor startup. |
| s.LevelStreamingComponentsRegistrationGranularity |
Batching granularity used to register actor components during level streaming. |