CustomDepthTemporalAAJitter Does Not Work

Hi everyone,

I’ve noticed an inconsistency with the r.CustomDepthTemporalAAJitter command. When disabling this feature (through the project settings or setting the Cvar runtime), it does not work on all objects that are drawn into the Custom Depth buffer.

Static Meshes are excluded from this feature entirely and they still exhibit the effects of the TemporalAAJitter when they are drawn into this buffer. Ideally this feature should be consistent across all objects that are marked for rendering into Custom Depth.

I’ve prepared a Demo scene to display the jitter.

Steps to repro this issue:

1: Load up the Demo Scene and hit Play

2: Press the 1 Key to toggle the CustomDepth visualization

3: Press the 2 Key to toggle the CustomDepthTemporalAAJitter command

4: Press the 3 Key, which will reduce the Screen Percentage size which will exaggerate the Jitter effect

I suspect this may be related to the DrawLists defined by the Primitive Scene Proxy, I may be able to circumvent this issue by creating a new one and forcing it out of the Base Pass, but any other suggestions would be helpful.


1 Like

I’m struggling with this same issue. I’m trying to make a simple, nice-looking post-process outline, and the Temporal AA is ruining the effect with its jittering.

As you said, Alex, changing the “Custom Depth with TemporalAA Jitter” setting in the project settings, or changing the r.CustomDepthTemporalAAJitter variable via the console, does not actually affect the custom depth pass. It continues to jitter away, and any post process materials that use the custom depth or custom stencil passes are negatively affected.

For my use case, many people have suggested setting the post process material to be applied before tonemapping. Doing so does reduce the apparent jittering, but this is a workaround and not a solution because it introduces other issues.

When scheduled before tonemapping, the jittering goes away because Temporal AA is later applied to the results of the outline post processing material. Unfortunately, this means other post processing effects (such as color correction) are also applied as well, which is not the ideal behavior in my case. Worst of all, when applied before tonemapping and before Temporal AA, the outline appears to fade in and out when the mouse is moved over and off objects quickly, because Temporal AA blends frames together over time.

Long story long, the ideal solution is for the material’s input — the custom depth or stencil pass — to not have the jittering issue to begin with. That’s what the r.CustomDepthTemporalAAJitter setting is supposed to do, but it doesn’t work the way I need it to.

I’ll try to send a note to Epic about this. Maybe it’s something they can improve in an upcoming version of the engine.

In the mean time, Alex, did you ever find a solution to this issue? Does anyone else have any ideas?

I wasn’t able to investigate this issue much further. If I recall, it was an issue that was specific to StaticMesh scene geometry, whereas skeletal meshes like characters seemed to behave correctly with this feature.

The only workaround I’ve found is to simply convert a static mesh into skeletal mesh like in the demo scene. It may work for things like pickups, but it isn’t really suited to doing custom depth on environments.

I’ll repost this to UDN and see if I can get some sort of response there.

So there’s a solution, and it’s a one line fix provided you can recompile the Engine source.

In FPositionOnlyDepthDrawingPolicy::SetSharedState , you simply need to change View->ViewUniformBuffer to DrawRenderState.GetViewUniformBuffer()

After this change, the feature works exactly as it should for all primitives.

Excellent! That did the trick alright. I appreciate your determination!

With that figured out, I guess I need to deal with softening my edge detection material to compensate for the aliasing that’s now left in the Custom Depth pass. Ah, another day.

Alex, did you determine whether this one-line change represents a bug? Or maybe some kind of weird intentional behavior that Epic has chosen for the engine?

In any case, nice work and thanks again.

sorry,can you explain where can i find this,i cant find it on source,thanks

how can i resolve this on 4.27?thanks