Hi
We have world space UI elements on a dashboard (imagine a digital car speedometer with dials)
The TemporalAA/TSR systems degrade the visuals of the UI elements as there is no velocity data for the elements themselves being animated
I wanted to use the Responsive AA option to clear this up, but that only works for Translucent objects.
Ours is opaque (as we need it to respond to lighting changes in the world)
In engine code, the ResponsiveAA stencil bit is
const uint kResponsiveStencilMask = 1 << 3;
Which resolves to 8. I tried setting this on the widget renderer, but this didn’t seem to work
In debug view I can clearly see its writing 008 to stencil, but the responsive AA doesn’t seem to activate for it as its still gets blurred
Any ideas on what we can do?
Thanks
A secondary problem to this
If I was to even use the translucent option
It doesn’t clear up the jitter from the AA
If I toggle between TAA and no AA
It still isn’t as clear
I think because of this line:
BlendFinal = InputParams.bIsResponsiveAAPixel ? (1.0/4.0) : BlendFinal;
If I change it to:
BlendFinal = InputParams.bIsResponsiveAAPixel ? 1.0 : BlendFinal;
This makes it just as sharp *but* the image is now jittering around because of the TAA camera sub pixel offsetting?
Could this be countered in anyway? like offset the read by subpixel in the reverse?
Hi Karl,
If I understand correctly, you have an opaque world-space dashboard object (such as the physical dashboard of a car) containing UI elements animated by their material and not by moving geometry. Pixel-based animations like these do not generate motion-vectors for the temporal antialiasing algorithm, which can cause it to make wrong calculations and heuristics-based decisions, resulting in ghosting and other artifacts.
The first thing I would try in this case would be to enable “Has Pixel Animation” in the details panel of the affected materials or material instances. This is probably the setting you are looking for. It will mask the pixels drawn with those materials so that they are ignored by the relevant parts of the temporal antialiasing process.
Note that making your materials translucent just to use ResponsiveAA will likely be counterproductive, since translucent materials usually suffer from more problems than opaque ones when using temporal antialiasing algorithms.
By the way, this doc has a wealth of information regarding TSR, including available debug tools and sections on both translucent materials and pixel-animated opaque materials.
Please let me know if this solution works for you or if you need any further assistance.
Best regards,
Vitor
Hi Victor, thanks for the info & yes you understood correctly
The issue with bHasPixelAnimation
Is that it only works for the TSR (r.AntiAliasingMethod = 3)
Not TAA (r.AntiAliasingMethod = 2)
We have to make this work on both. As TSR can quite expensive in some setups, and for us has serious artifacting issues currently when working with reflective wet surfaces
Looking at references to bHasPixelAnimation in code it’s clear that the standard TemporalAA pass totally ignores that information. The TemporalAA pass instead has the references to that ResponsiveAA
Curious as to why this is, if it was a deliberate choice to do this or just an oversight
Thanks
Karl
hmm strangely
The debug view shows bHasPixelAnimation isn’t respected on my in world widget element
Fine if I use the same material on say a cube in the environment
Hi Karl,
It seems that bHasPixelAnimation was created primarily for TSR’s anti-flickering heuristic. It might end up being useful for TAA or other algorithms as well, but not sure of how helpful it could be to TAA specifically.
Also, I’d like to ask for one clarification: are you using Widget Components in world actors, or applying a UI-like material to a regular static mesh component? If using Widget Components, have you tried to set their “Space” to “Screen” instead of “World”?
In any case, I’ve been reviewing some suggestions given by Epic staff in other similar questions. One suggestion that helped improve the quality of my test scene here (but that might adversely affect the effectiveness of the TAA elsewhere) is increasing “r.TemporalAACurrentFrameWeight”.
Another suggestion is to mark your objects in the CustomDepth or CustomStencil buffer, then using that as a mask in a Post Process Material after antialiasing to composite the UI cleanly over the scene (more information here).
Alternatively, you could render your UI actors (with “visible in scene capture only” enabled) into a rendertarget using the SceneCapture2D component with antialiasing disabled (or set to a different method), then manually composite it over the scene. This does require constantly matching the SceneCapture2D transform to the current camera (e.g. on a “Post Update Work” tick), and the RenderTarget dimensions to the viewport dimensions as well, so it can take a while to get right.
Finally, I’ve also seen suggestions that involve making changes to the engine source code. For example, [Content removed] discussion mentions using FWidgetRenderer to implement a custom solution, and [Content removed] discussion mentions looking into how the Editor renders transform widgets and other elements that are not affected by post-processing. Also some other discussions for reference: [Content removed] [Content removed] [Content removed] [Content removed]
If none of these approaches seem to work or be viable for you, I can try to get someone from Epic to chime in here and maybe offer some more ideas.
Best regards,
Vitor