Fix for VR Deferred rendering in UE 5.6

In UE 5.6 there was an issue introduced that broke camera late updates and caused images in the HMD to look “smeared” when using DX12 and the Deferred Renderer. We were able to fix the issue but it was too late for the 5.6.1 hotfix. If you’re working with a source build of Unreal Engine you can cherry pick this change or use UE5/Main.

Let us know if you have any issues using the fix, thanks!

11 Likes

These are great news. I’ll build during the weekend and report back

It seems to have fixed it for me,

will this be in an potential official 5.6.2 hotfix?

1 Like

Still TBD - I’ll update this thread as soon as we know.

1 Like

Cannot find github link anymore

You need to link your GitHub account to your Epic account in order to access the engine source code: https://www.unrealengine.com/en-US/ue-on-github

Will this fix be in 5.6.2? ETA?

2 Likes

Dear Victor Lerp, thank you for the fix code. I tested it in the editor and it works very well. But when I was packaging, I found that this fix patch did not exist and still had no effect in the packaging. May I ask how I can operate or choose to compile the code to ensure that it can also solve this problem after packaging? Looking forward to your reply and guidance

@VictorLerp Hi Victor - I am in a bit of a spot: I started a VR project in 5.6.1 and rendering is all kinds of broken. However, I need the Meta XR plugin which has not been updated for 5.7 yet. How can I go about getting the fix in 5.6 or recompiling the MetaXR plugin for 5.7? Thanks!

Hi @VictorLerp
Thanks for the fix! It successfully resolved the smearing issue in the general case.

However, I noticed that the smearing on the HMD returns if I place and activate an actor with a SceneCaptureComponent2D in the level. I was able to reproduce this behavior in the VR Template by simply adding an actor that contains a SceneCaptureComponent2D.

Is there any additional patch or workaround for this specific situation?

The capture is still smeared in UE 5.7.1 when using SceneCaptureComponent2D. I have submitted a bug report for this: Case # 23082743.

Settings:

  • Based on VR Template

  • Forward Shading: OFF

  • Anti-Aliasing: TAA

The VR Template contains a SceneCaptureComponent2D in the VR Spectator Actor which is default in in the template Map. As we’re not able to reproduce it there, there’s something else involved - could you provide us with the full steps you’re taking to reproduce it?

Here are the reproduction steps:

  1. Create a new project using the VR Template.

  2. In Project Settings, uncheck [Rendering] > [Forward Shading], set [Rendering] > [Anti-Aliasing Method] to TAA, and restart the project.

  3. Create an Actor with a SceneCaptureComponent2D (ensure a TextureTarget is assigned) and place it in the level.

    • Note: The issue also reproduces if you enable CaptureEveryFrame on the SceneCaptureComponent2D of the BP_VRSpectator which is already placed in the map.
  4. Run VR Preview.

We’re having this exact same issue, but using TSR.
Scene with SceneCaptureComponent2D unhooked, it renders fine. Once hooked up, even though it’s not being viewed, causes extreme smearing in the VR View.

Tried many settings and nothing fixes it so far. If you find a fix, please let us know!!!

Im also having issue with TSR (DLSS really) + SceneCaptureComponent2D as the spectator screen source.
Can’t use them together or it will smear and shake the VR camera.
I applied the fix provided but it doesn’t help.

What framerate are you running at? We tested and the smearing we’re seeing is due to poor framerate and runtime reprojection. If you can reproduce the issue at device target framerate, we’ll take a look at it again but the results we’re seeing is expected due to how expensive a 1920x1080 scene capture each frame is w. the full Deferred Rendering stack in a Default configuration.

The issue reproduces even when the Texture Target resolution is set to 1x1. At this resolution, the cost should be negligible, yet the artifact persists.

I am running at a stable 72 FPS, so I do not believe this is a reprojection artifact caused by poor performance.

THIS one QA’s! Thanks I’ve logged it

1 Like