Previous closed post: [Screen distortion [Content removed]
Hi,
Since the original post was closed, creating a new one to continue the discussion here. (Apologies for the delay, was heading to vacation)
We made a few tests in the past and can confirm that after setting the r.SeparateTranslucency=0, theproblem went away. Regarding PLATFORM_ASSERT, do you have a particular shader in mind? Or this supposed to be used in materials somehow?
- Thank you
[Attachment Removed]
Hello,
Is this issue something you can reproduce in a vanilla UE project and send to us so we can troubleshoot it?
I had in mind that you could use the PLATFORM_ASSERT to validate the rects used in the hlsl shaders used for separate translucency rendering depending on what you have enabled:
SeparateTranslucency.ush
ComposeSeparateTranslucency.usf
DOFRecombine.usf
MotionBlurApply.usf
[Attachment Removed]
Sorry, missed the notification that there was a reply in a post.
> Is this issue something you can reproduce in a vanilla UE project and send to us so we can troubleshoot it?
Unfortunately, we can reproduce the issue only on specific QA machines. If we manage to get to the point of what material/shader is causing it, I could try to re-create it in vanilla UE and send it over.
Could you please post an example of how you expect it to be validated? I’m not that familiar with rendering/shaders, unfortunately, not to mention what values I should expect to validate against.
[Attachment Removed]
Actually, I’m not convinced the translucency passes controlled by r.SeparateTranslucency are necessarily the issue because I tried replicating it in a couple places where it might make sense to check UVs and view rectcs, and didn’t get the same behavior. It’s possible that turning off separate translucency makes a driver issue less likely to happen because it avoids the extra render target usage and viewport setting etc.
One place I tried replicating this issue was by modifying ComposeSeparateTranslucency.usf to force the scale to be wrong, but it doesn’t show the CLAMP border behavior:
float4 SceneColorSample = SceneColorTexture.SampleLevel(SceneColorSampler, SceneColorUV * 2.0, 0); [Image Removed]I also tried reproducing it in PostProcessToneMap.usf because that’s where Bloom is composited, but it also doesn’t cause the expected CLAMP.
float4 SampleSceneColor(float2 SceneUV, float ArrayIndex)
{
// Test Invalid UVs
//SceneUV = clamp(SceneUV, Color_UVViewportBilinearMin, Color_UVViewportBilinearMax);
SceneUV *= 2.0;
[Image Removed]I want to try a couple more places, but it would help to know what passes are active in your scene when the issue occurs.
When r.SeparateTranslucency=0 the translucency and distortion are applied to SceneColor which TAA then reads and uses to update the TAA.History (if you’re using TAA). When r.SeparateTranslucency=1 translucency and distortion are written to different render targets - one for materials using After DOF (default) and one for materials using After Motion Blur. The translucency is merged with scene color in various places, either PostProcessing > ComposeToNewSceneColor, or DOF Recombine, or Motion Blur Filter.
If you can narrow down what passes you have enabled when the issue occurs with r.SeparateTranslucency=1 by taking a PIX or RenderDoc capture under the same conditions when the issue usually occurs and share the active passes that would help determine what to look at.
[Attachment Removed]
Hey Alex,
Sorry for waiting.
I’ve tried to reproduce it again with capturing software, but had no luck. I’ve captured two different frames with Nvidia Graphics and Render Doc.
https://drive.google.com/drive/folders/1M4iJSmRpzPFHB_OC1oXkJDRTVuBnaELu
I’ll grant access once it is requested.
[Image Removed] [Image Removed]One thing to add. Our QA team noticed that the issue is much easier to reproduce having DLSS and Frame Generation turned on. This issue can be spotted in other unreal engine based games. It is still possible to reproduce it without DLSS, but with a much lower chance.
Let me know if there’s anything else needed.
[Attachment Removed]
Thanks, I’ve requested access. I’m not surprised the captures don’t show the issue because that has also been my experience with this. Taking a PIX/NSight/Renderdoc capture messes with the timing/synchronization and causes the issue to not be visible - however, you can often see the issue was occurring in the previous frame before the capture by looking in the contents of the previous framebuffer. One thing you might try is to use the DumpGPU console command when the issue occurs, however I suspect that will also insert transitions that make the issue go away.
[Attachment Removed]
Hey Alex,
Did you have a chance to download captures?
Also, I’ve managed to reproduce the bug locally, but it shows only for a few frames. Will do a few more tests to see if I can catch it for the DumpGPU command you mentioned earlier.
[Attachment Removed]
Hey [mention removed], just wanted to let you know that I’ve managed to catch the issue with DumpGPUconsole command. Dump is already uploaded to shared google drive folder.
[Attachment Removed]
Thanks for providing the captures! Unfortunately they don’t catch the pass that is causing the issue, however seeing what passes are involved I think the first place to look is:
On the CPU, most of the translucency passes responsible for upscaling are in FTranslucencyComposition::AddPass so you may want to add some sanity checking in that pass to verify none of the upscaling render target parameters at the end are the wrong sizes for your test case, namely OutputViewport.Rect and TranslucencyTextures.ViewRect. Also look for wrong values when setting up the UVs used from separate translucency (also in FTranslucencyComposition::AddPass). If you can capture these UV parameters when the issue repros it can help rule out the possibility of a bug in the CPU-side math.
PassParameters->ScreenPosToSeparateTranslucencyUV = SvPositionToViewportUV * FScreenTransform::ChangeTextureBasisFromTo(
TranslucencyViewport, FScreenTransform::ETextureBasis::ViewportUV, FScreenTransform::ETextureBasis::TextureUV);
PassParameters->SeparateTranslucencyUVToViewportUV = FScreenTransform::ChangeTextureBasisFromTo(
TranslucencyViewport, FScreenTransform::ETextureBasis::TextureUV, FScreenTransform::ETextureBasis::ViewportUV);
PassParameters->ViewportUVToSeparateTranslucencyUV = FScreenTransform::ChangeTextureBasisFromTo(
TranslucencyViewport, FScreenTransform::ETextureBasis::ViewportUV, FScreenTransform::ETextureBasis::TextureUV);
PassParameters->SeparateTranslucencyUVMin = (FVector2f(TranslucencyViewport.Rect.Min) + FVector2f(0.5f, 0.5f)) * SeparateTranslucencyExtentInv;
PassParameters->SeparateTranslucencyUVMax = (FVector2f(TranslucencyViewport.Rect.Max) - FVector2f(0.5f, 0.5f)) * SeparateTranslucencyExtentInv;
PassParameters->SeparateTranslucencyExtentInverse = SeparateTranslucencyExtentInv;
In these captures where the issue occurs it looks like there are multiple translucent materials, some writing to AfterDOF and some to AfterMotionBlur. If the issue only occurs when you are writing translucent materials in both places, that might make it easier to repro.
I also see you have dynamic resolution enabled, des this issue occur without dynamic resolution - or with a fixed screen percentage (r.DynamicRes.TestScreenPercentage)?
[Attachment Removed]
Bumping the thread so it remains open. Sorry, busy with something else, but I’ll get back to it.
[Attachment Removed]
Good day, everyone.
I’ve been hovering this thread for a few days now, because we are experiencing a very similar, if not the same, issue.
With what has been shared in this thread so far, especially by Alex Peterson, I’ve spent a bit of time trying to debug the problem.
First of all, I haven’t figured it out yet, but I might have gathered a bit of information that might generally help.
I can’t publicly share much about the game itself, so if any kind of file is needed, we would also need to go the “private file share” path, similar to Dmytro Kondratishyn.
Next, I’m gonna quickly explain what is happening on our end.
Whenever we have the AA method set to TAA and a scope (weapon scope) with a specific material is on the screen, the screen might start “flickering”.
“Flickering” here means that the final render of the game rapidly switches between the normal, functional case and the broken case.
The function case is simply how anyone would expect the game to look, with the final render fitting the size of the window/monitor.
I usually reproduce this in Window Mode, but others have had it in either Fullscreen or Windowed Fullscreen as well.
The broken case, however, shows either a zoomed-in or a zoomed-out version of the game.
With that out of the way, I’ll now list a few notes that I gathered that might help understand where this is coming from.
Furthermore, a few things I’ve noticed, which don’t necessarily need to mean anything or be the same for others, but I think they are worth sharing.
[Attachment Removed]
Hi,
The original post mentioned the issue was occurring in UE 5.4 and we’ve had several related fixes in UE 5.5 that might be worth back porting:
CL#36342712 Fixed parallel translucency not using the correct viewport scale.
In UE 5.6:
In UE 5.8:
I haven’t been able to reproduce the issue after commenting out the `ViewFamily.AllowTranslucencyAfterDOF()` case inside `FDeferredShadingSceneRenderer::RenderTranslucency`.
Blend after DOF is the default blending location for translucent materials - does the scope material use it? If that’s the only translucent blending that is occurring when the flickering occurs for you that can help narrow down where the race condition is happening. If you are able to provide a simple repro project in vanilla UE for us that would also help.
Also, Epic will be on holiday break starting next week (Dec 22, 2025) and ending Jan 5, 2026 and there will be no responses from Epic on public or private tickets, though you may receive replies from the community on public tickets.
We wish you happy holidays!
[Attachment Removed]
Don’t know what the usual time is before a post gets auto-closed, so bumping it for now.
[Attachment Removed]
Hello there !
I have been looking at this thread (and others like it) for a while because we also had a similar issue (very likely the same one).
Pretty much exactly what Dmytro Kondratishyn reported in his original post [Content removed] and that I have seen reported in multiple other posts before but none had an actual solution yet (the bug is really hard to repro and only seems to happen in very specific settings, and I don’t think Epic had a repro for it).
Some posts for example :
[Screen [Content removed]
[NVIDIA DLSS enabled causes screen [Content removed]
…
it was also reported in NVidia forums for DLSS a while ago (but I don’t think it’s DLSS specific, I had the bug happens with TSR too and had reports about others also seeing it with differents upscalers) :
Anyhow, I worked quite a bit on trying to fix that bug in our game and wanted to share what I saw and the workaround I did which so far seems to work for us in case it helps someone find the real issue (I’m really curious to know what it is if someone finds out).
Since I pushed my workaround, I haven’t seen or heard about that bug so I assume it might be fixed, though that bug was extremely hard to repro and as far as I can tell, it seems timing-related so it might just be “hiding” again.
So, first things first, in our case, the bug seemed to only happen only in very specific setups :
Anyhow, since disabling separate translucency was fixing the issue, I looked mostly at it and ended up finding out that changing inside “FScreenPassTexture FTranslucencyComposition::AddPass” in “TranslucentRendering.cpp” :
PassParameters->SceneColorSampler = TStaticSamplerState<SF_Point>::GetRHI();to :
PassParameters->SceneColorSampler = TStaticSamplerState<SF_Point, AM_Wrap, AM_Wrap, AM_Wrap>::GetRHI();Instead of getting the “stretching” bug effect, I got multiple times the same scene color repeating on screen.
So, I thought it was probably an issue of UVs or Render target resolution in one of the “ComposeTranslucencyToNewSceneColor” passes (“AfterDOF” or “AfterMotionBlur”).
Which is why I tried a few things :
Doing this I still saw the stretching bug.
Thing is, since there was two “ComposeTranslucencyToNewSceneColor” passes (“AfterDOF” and “AfterMotionBlur”), one before the TSR (or DLSS, …) upscaling and one after, I had a bit of noise with my “coloring mask” since it was applied in both passes, so I wanted to make it cleaner and added a boolean sent to the shader which was true only for the “AfterMotionBlur” pass and false otherwise and I used that boolean in the shader to only apply my coloring scheme if the bool was true (so only for “AfterMotionBlur” and NOT for “AfterDOF”)
I STILL had the bug this way but here is the interesting part :
So, ultimately, to fix that issue, I created a shader permutation and added something like this :
// Final composition
OutColor.rgb = SceneColorSample.rgb * SeparateTranslucencySample.a * SeparateModulationSample.rgb + SeparateTranslucencySample.rgb;
//----------------- start of my change --------------------
#if PERMUTATION
OutColor.rgb = max(0.0f, OutColor.rgb);
#endif // PERMUTATION
//----------------- end of my change --------------------
Towards the end of “MainPS” in “ComposeSeparateTranslucency.usf”.
(The “max(…)” doesn’t do much in theory but without it, the bug was still happening, the important thing is that there is some code to make the shaders distinct).
So, my current unproven theory is that somehow when the bug happens, the second “ComposeTranslucencyToNewSceneColor” pass “AfterMotionBlur” is using some binding/UVs or rendertargets from the first “ComposeTranslucencyToNewSceneColor” pass (“AfterDOF”) which has different render target sizes and UVs (one pass is before upscaling, the other after).
I don’t quite understand how or why it would happen but that is what I’m currently thinking is happening. By creating a shader permutation and adding some small change to make the shaders distinct (even changes which shouldn’t really do anything), I guess I am “forcing” the two “ComposeTranslucencyToNewSceneColor” passes to each actually use the right shader / bindings.
Anyway, I’m not looking at this bug anymore for now since it does seem to be gone in our case with that workaround (I submitted this workaround in our code a bit more than a month or two ago I think), I just wanted to post this in case you want to try it on your end and maybe it might help people to find the real cause of the issue and the right fix.
Best regards,
JB
[Attachment Removed]
Thanks for posting your in-depth investigation details and workaround. It does appear that all the known cases of this point to the ComposeTranslucencyToNewSceneColor after motion blur being a key player in this issue. We’re discussing this internally - do you still have the capability to reproduce the issue if we provide other ideas to try?
[Attachment Removed]
I haven’t tried recently after pushing my workaround. And we did change other things later on which might affect the timing, so I’m not sure if I can reproduce it or not anymore after removing my workaround. I’ll give it a try if I have some time
[Attachment Removed]
Hello,
Have you had a chance to test after applying this fix?
[Attachment Removed]
Hi,
We haven’t had any new ideas yet about what’s going on here aside from the fix mentioned above (CL#48075147). If we can get a solid repro, preferably in latest, that would give us something to investigate.
Have you also tried adding a separate shader permutation for the ComposeTranslucencyToNewSceneColor like Jean-Baptiste Font did? That might be a valid workaround if this is a driver issue with the bindings.
Would it be possible to share the repro you have with us and what GPU and driver versions we can repro it with?
[Attachment Removed]
Hello,
I found these issues which are possibly related:
[Content removed] (Related public issue: https://issues.unrealengine.com/issue/UE\-243388\)
[Content removed]
[Attachment Removed]
Hi,
The issue (https://issues.unrealengine.com/issue/UE-243388) is triaged but the priority is low, if I can reproduce the issue in latest I’ll see if I can escalate having it looked at by the team. It’s possible CL#48075147 or some other change has fixed this in latest, but we’ll see.
[Attachment Removed]