TAA and FXAA alpha inversed issue

Hello!

We have a dev branch that is based off the UE 5.5 branch as of about a couple months ago. Just for context, we use forward shading and are on OpenGLES 3.1, Vulkan disabled, with Android Single Instance Service. On one of our UE android services, we use FXAA exclusively. On the other, we mainly use Gen-4 TAA when the camera is still, and then switch over to FXAA during the short camera transitions to prevent ghosting visuals.

There are two problems which have come up.

  • Issue #1: When we first moved to UE5, for some reason the alpha values were inversed when using FXAA only on our Android target (not desktop). As a temporary solution, we modified the Engine FXAAShader.usf and inversed the alpha before the shader returns, specifically added this line at the end of `void FxaaPS()`:

#if DIM_ALPHA_CHANNEL == 0

OutColor.a = 1.0;

// [DIVERGENCE][START]

#else

OutColor.a = 1.0 - OutColor.a;

// [DIVERGENCE][END]

#endif

This is what it looked like before the temporary fix:

[Image Removed]

And after:

[Image Removed]

So for this we wanted to check if there is anything we might be doing incorrectly to cause the alpha to be inversed so we can remove this temporary alpha inverse? We have this PostProcess Material that is only adding a mask:

[Image Removed]

  • Issue #2: On our other Android UE service, as mentioned above we have Gen-4 TAA for the most part, unless during one of our short camera transitions, we temporarily switch to FXAA. We have set the following TAA CVARs which helped lower GPU usage (other ticket: [Content removed]

r.TemporalAA.UseMobileConfig=1

r.TemporalAA.Mobile.UseCompute=0

r.TemporalAA.Upscaler=0

r.TemporalAA.Upsampling=1

r.TemporalAA.Quality=0

And these regarding propagate alpha:

r.Mobile.PropagateAlpha=1

r.PostProcessing.PropagateAlpha=True

When we originally tried setting r.TemporalAA.Upsampling=0 (as suggested in the other ticket mentioned above), that would cause the alpha to be inversed and thus make the image look very washed-out. So we kept it that CVAR set to 1 and it was fine. However, there has been a couple of instances over the past few weeks where seemingly random the alpha would be inversed again even without changing that CVAR. Locally I then tried setting that Upsampling CVAR to 0 which somehow fixed it. Then a few days later had to change it back to 1 to fix it again.

When I change that Upsampling CVAR to temporarily fix the render, then at the times where there is a camera transition and we switch to FXAA, that alpha would be inversed also and the render looked washed out (probably because of change we made for the first issue). *I have attached a video of this happening.*

We are not exactly sure what is causing this as we have checked our commits and haven’t made any changes that should touch any of this stuff. Could it be some kind of issue where when we locally build the two services in order to side-load, some cached shader files or uasset files are causing issues?

Image when issue occurs:

[Image Removed]

Image when I swap value of r.TemporalAA.Upsampling locally to fix it:

[Image Removed]

**One thing that I just noticed as I was typing this up, is that when I set Screen Percentage from 115 down to 100, then no matter what Upsampling is set to, the alpha issue happens. If I put it back to 115, then the above happens and currently setting Upsampling to False will fix the issue while the camera is not in transition.

One other note is that in Android if I set the textureVIew to be Opaque, then it all looks fine.

If there is any further information we can provide, please let us know!

Thanks!

Nevin

Hi Nevin,

As far as you’ve been able to observe, is the alpha correct prior to the AA passes? Are you able to provide a RenderDoc capture of the correct and incorrect cases?

Best regards.

Hey Stephane,

Sorry for the late reply. So it seems when running via standalone APK, which is required to run RenderDoc, then the issue doesn’t happen. It seems like it’s likely related to Android Single Instance Service or some part of it at least.

I can still provide a renderdoc capture with the standalone apk where the issue doesn’t happen if that helps?

Nevin

Hi Nevin,

A capture would be great to confirm when you are able to provide it. I am not aware of ASIS triggering differences in the render path but we’ll need to confirm.

Best regards.