We’re hitting this assert in SceneView.cpp
checkf(Family->GetTemporalUpscalerInterface() == nullptr, TEXT(“ITemporalUpscaler should be set up in FSceneViewExtensionBase::BeginRenderViewFamily()”));
when FSR or DLSS is enabled and a SceneCapture component with RenderInMainRenderer enabled is capturing depth. Disabling RenderInMainRenderer avoids the assert but the performance loss is not desirable. Just commenting out the assert appears to work but I want to ask if you might have any concerns about doing that or a better fix proposal?
[Attachment Removed]
Hi Georg, thanks for reaching out. I took a look at your suggestion and have some thoughts. In UE 5.4, that child view family inherited the main family’s temporal upscaler, so the assert in FSceneView::SetupAntiAliasingMethod() then fires, because a capture pass should never carry an upscaler (it has no color/history input to upscale). We did have a more comprehensive rework of the SceneCapture framework added in 5.5, which fixed this issue. You can try backporting the official engine fix from CL 33538227, but it is a big change, and you only need a few lines from it. The change builds the Custom Render Pass view family from scratch, so the upscaler and related interfaces are never copied onto it. The relevant lines are at SceneRendering.cpp:3167:
// We construct from scratch, rather than copying, as we don't want to copy interfaces attached to the view family (ScreenPercentageInterface, TemporalUpscalerInterface, etc), which can assert or double free if copied. Those aren't relevant for custom render passes anyway.
FSceneViewFamily::ConstructionValues FamilyCVS(ViewFamily.RenderTarget, Scene, ...);
This keeps the assert in place rather than turning it off and properly constructs the view family. Try integrating this change and let me know if it fixes your issue, otherwise, we can look into some alternatives.
[Attachment Removed]
Thank you for the suggestion Tim. I didn’t have permission to view 33538227 but I found 33538231. I integrated most changes from that (and 33572888), but skipped anything relating to the addition of ERenderOutput::BaseColor and Normal since that didn’t seem relevant. The GetTemporalUpscalerInterface assert no longer triggered.
Since there were more changes than just some trivial local change in that for loop, I’ll have to have some discussion and review tomorrow to see if we can or want to apply the changes at this late stage, and more testing to make sure no new issue was introduced.
[Attachment Removed]
Hi Georg,
That sounds good to me! To close the loop on this ticket, I wanted to see if you were able to resolve your issue. Did you encounter any issues in the meantime?
[Attachment Removed]
Interesting, I have not heard of that before. If you do not find a root cause, feel free to share your project, and we can try to take a closer look.
[Attachment Removed]
Thanks for letting us know. I’ll make sure to mark your answer as Best to let people know of your resolution. If anything else comes up, please don’t hesitate to reach out.
[Attachment Removed]
We’ve decided to use the fixed code, but in later builds. That opens up the question with the current build just ignoring the assert, do you see any dangers with that? We haven’t noticed any side effects in testing/QA so far.
[Attachment Removed]
Hi Tim,
One rendering artifact* came up in testing with the backported fixes. I started investigating which change in particular may be causing it or if I missed a change, but had to pause that for some higher priority tasks. I’ll get back to the investigation a bit later and if I can’t resolve it then was may have live with the removed assert.
*) In one place of the game with some animated SKM, a few vertices flipped out causing polygon spikes from the mesh. It’s odd that it only seems to happen one that one mesh which isn’t especially unique afaik, but it’s 100% repro rate. With different builds and on different computers, and it doesn’t happen without the fixes.
[Attachment Removed]
I had some time to revisit the issue now. It appears to have been some strange issue with a specific mesh asset (and a generated lod it was using).
Turned out the mesh bugs also appeared in an exported fbx, but only from my task stream even though uasset file is identical to one that works for others. Anyway when I applied Recompute Normals on the mesh the glitches went away for me, so the preliminary conclusion is that the glitch is unrelated to the backported fixes and that they work.
[Attachment Removed]