Distance Field Ambient Occlusion artifacts when using dynamic resolution

Hello!

We discovered a graphic glitch when combining DFAO with dynamic resolution. We notice the issue as a displaced character ghost, just as if the AO was being applied at the wrong screen coordinates (please see the video and sample project attached).

We think we isolated the cause of the issue in the code of UpdateHistoryDepthRejectionPS shader (Engine\Shaders\Private\DistanceFieldLightingPost.usf). It seems that the velocity buffer is not being sampled with the right coordinates or so when the dynamic resolution is involved. The shader approximates the ScreenVelocity first using this code

float4 ThisClip = float4(UVAndScreenPos.zw, ConvertToDeviceZ(SceneDepth), 1);

float4 PrevClip = mul(ThisClip, View.ClipToPrevClip);

float2 PrevScreen = PrevClip.xy / PrevClip.w;

float2 ScreenVelocity = UVAndScreenPos.zw - PrevScreen;

and then, the calculated velocity is overridden if the sample value of the velocity texture is non-zero:

// The scene velocity texture is rendered as a texture atlas for all views,

// so first convert the vertex shader’s UV coordinates to the size of the view rect and offset into the atlas

// before converting back to the correct UV coordinates.

float2 FullResTexel = (UVAndScreenPos.xy * View.ViewSizeAndInvSize.xy + View.ViewRectMin.xy - .5f) * View.BufferSizeAndInvSize.zw;

float4 EncodedVelocity = Texture2DSampleLevel(VelocityTexture, VelocityTextureSampler, FullResTexel, 0);

if (EncodedVelocity.x > 0.0)

{

ScreenVelocity = DecodeVelocityFromTexture(EncodedVelocity).xy;

}

As said in the shader code comment, the velocity texture is some sort of atlas, and it could be that the coordinates to sample it are miscalculated in the case of using multiple viewports (editor) or when dynamic resolution is enable (for instance in consoles). If we comment the code that samples the screen velocity from the velocity texture, the glitch dissapears.

We have been seeing this glitch since UE 5.6 at least. We are on 5.7.3 and the issue is present too. We are able to reproduce it on all consoles.

Is there a known way to fix it within UE 5.7.3 or is there a workaround?

Thanks in advance.

Regards,

Marcos Falcón Pérez

Tech Director

Saber Interactive

[Attachment Removed]

Steps to Reproduce
1. Make a new project in stock Unreal Engine (we used UE 5.7.3).

2. Use Third Person Template.

3. In Project Settings, set “Dynamic Global Illumination Method” to “None”.

4. In Lvl_ThirdPerson create a rendering-intensive area. In our case, we generated thousands of translucent boxes.

5. Make a console build including that map.

6. Run the build.

7. Make sure Dynamic Resolution is enabled: (i.e. using console command “r.DynamicRes.OperationMode 2”).

8. Make sure Dynamic Resolution is scaling (for instance go to the rendering-intensive area). You can check it by watching DynRes value changing, using stat detailed.

9. Move the character while Dynamic Resolution is scaling.

10. See the AO artifacts on the right of the character.

[Attachment Removed]

Hello,

Thank you for reaching out.

I’ve been assigned this issue, and we will be looking into the Distance Field Ambient Occlusion artifacting for you.

[Attachment Removed]

Hello,

Thank you for reporting this. I can confirm this issue can be reproduced as described in the latest CL, and will open a bug report.

As a workaround, you can set r.AOUseHistory=0 to disable history usage for Distance Field Ambient Occlusion.

We will reply with a public tracker when one is available.

[Attachment Removed]

Hello,

Here is the public tracker for the issue:

https://issues.unrealengine.com/issue/UE\-369654

If you have any further questions, please let us know.

[Attachment Removed]

Hey Stern,

Thank you for suggesting the disabling of AO history as a workaround. Unfortunately, disabling the history causes other artifacts that lower the image quality by displaying lots of flickering. Please take a look on the new video attached with the comparison using the same sample project.

That said, is there any time frame to have the issue fixed? We can cherry pick any CL you provide and test the results.

Regards,

Marcos.

[Attachment Removed]

Hello,

We cannot give any estimate as to when the issue will be resolved.

[Attachment Removed]

Hi,

Ok. If at any point in the near future you have a tentative fix, no matter if it’s not ready to publish to main UE5 branch, please let us now.

Regards,

Marcos.

[Attachment Removed]

Hi Marcos,

If at any point in the near future you have a tentative fix, no matter if it’s not ready to publish to main UE5 branch, please let us now.

Our public issue tracker is our mechanism for making developers aware of fixes and workarounds. We don’t currently have a mechanism for automatically notifying developers when work is done on an issue that doesn’t result in the issue being updated publicly. My recommendation is to reach out again on Epic Pro Support in the near future if you don’t see an update on the public tracker.

[Attachment Removed]

Hi Alex,

Sorry for the late response. I’m aware about the issue tracker policy. Nevertheless, in similar circumstances, we usually receive a kind update on the thread once the engineer has applied a fix in UE main branch so we can cherry pick the CL if it’s suitable and patch our engine copy before the official release.

If this won’t be the case, no problem. We will monitor the issue tracker.

Regards,

Marcos

[Attachment Removed]

Nevertheless, in similar circumstances, we usually receive a kind update on the thread once the engineer has applied a fix in UE main branch so we can cherry pick the CL

That’s a good point, we do usually post an update to a question if the fix is made before the thread gets auto-closed and will likely do that here. However, the process isn’t automated it’s just best effort. The internal issue is assigned but work hasn’t begun yet.

[Attachment Removed]

Thank you very much!

[Attachment Removed]

Hey!

Thank you.

[Attachment Removed]