[4.15 p2] MSAA and Alpha2Coverage problem

Development Rendering
, , , , ,
1

Hello!

The forward renderer is really awesome. But with MSAA and masked materials, too much of the texture is masked out by default. It is worse with 2x MSAA than with 4X.

Here is an image using the UE4 VR template and Epic assets to illustrate the problem.

124315-msaa.jpg
124315-msaa.jpg800×2740 666 KB

To fix this, the opacity mask clip value has to be lowered by a significant amount. So i ended up with a workaround. Changing the DiscardMaterialWithPixelCoverage fuction in MaterialTemplate.usf to adjust the clip values globally, when MSAA is on. Scaling MaskClip by 0.1 fixed the issues.

I’am not sure if this is a bug, but it would be good if this would somehow work by default, so that masked materials look the same with all Anti-Aliasing methods.

Brest Regards

2

I noticed this as well. It’s an issue with speedtrees as leaves also get smaller when you go further away from the tree. Effect is so bad that the leaves almost vanish in the end.

3

Hey guys,

So what you are seeing is expected since Alpha to Coverage is not yet supported with MSAA and Forward Rendering. We have plans to get this implemented, but I do not currently have a timeframe as to when that will be. For now, I would use your global clipping value workaround.

We highlighted these unsupported features in the 4.14 Release notes which you can view by following the link I have provided below.

Thank you,

4

Thanks for the headsup.

The behaviour of masked materials in 4.15 is different than in 4.14 and Alpha to Coverage is listed as supported feature here. Forward Shading Renderer in Unreal Engine | Unreal Engine 5.1 Documentation

In 4.14 there was no Anti-Aliasing at all on masked materials. And in 4.15 Alpha to Coverage is mentioned alot in the shader code. It just has the bug, of masking out too much from the texture, but the Anti-Aliasing works.

5

Okay, well I am going to get clarification on whether or not it is officially supported in the 4.15 release, but I entered a ticket to have the information clarified and uniform.

Once I get the answer, we can investigate more into the issue you are experiencing. I will say that the large disclaimer at the top of the documentation link you provided applies to all the associated features, so it is expected certain features are not production ready yet.
Thanks,

6

Thanks! Some clarification would indeed be good. But yea, i understand that the “experimental” applies to the listed features aswell. I’am fine with the workaround right now.

7

Also, here is the simple workaround. A function change in MaterialTemplate.usf . Line 1739 .

uint DiscardMaterialWithPixelCoverage(FMaterialPixelParameters MaterialParameters, FPixelMaterialInputs PixelMaterialInputs)
    {
    	ClipLODTransition(MaterialParameters);
    	float OriginalMask = GetMaterialMaskInputRaw(PixelMaterialInputs);
    	float MaskClip = GetMaterialOpacityMaskClipValue();
    
    	if (View.NumSceneColorMSAASamples > 1)
    	{
    		MaskClip = MaskClip * 0.05; //Workaround for Alpha2Coverage
    		
    		float Mask = (OriginalMask - MaskClip) / (1.0 - MaskClip);
    		uint CurrentPixelCoverage = GetDerivativeCoverageFromMask(Mask);

    		clip(float(CurrentPixelCoverage) - 0.5);
    		return CurrentPixelCoverage;
    	}
    	clip(OriginalMask - MaskClip);
    	return 0xF;
    }
8

Alpha to coverage in the forward renderer with MSAA is indeed a new supported feature in 4.15. Thanks for pointing out the coverage difference vs non-MSAA. We’ll investigate and find a solution for this. I don’t know when we’ll get to it though.

9

Great to hear ,thanks!

10

Thank you for posting a workaround. I tried this and while it helped a little bit the fading problem still seems to exist after the 4.15 update. The pictures you posted were relatively close to the trees but in practice things are much worse when farther away in a more realistic scenario.

I’m wondering if there is some way to disable this new alpha to coverage feature completely? I really like the new renderer especially for MSAA but after this update things just look ridiculous. I’m really surprised this slipped through the cracks because it’s extremely noticeable especially when opening any nature map.

11

Just found this thread after I posted here:

Is this the same problem? I’m using a BP only project so this workaraound doesn’t work for me…

12

Hey andtheand,

It does look like your issue could be from MSAA alpha to coverage. We are aware of issues like this, and you we ask you remain patient until we can officially address for an upcoming release.

We have no timeframe, and the only suggestions I have would be to try and edit the masked clipping value within your material, or disabling the Forward Renderer and stick with the default method of Temporal AA.

Thank you,

13

please give this problem some priority. For every VR project MSAA is essential but can’t be used in any nature environment with this behaviour. Thanks!

14

Thanks Andrew, this works.

It can also be added to GetMaterialMaskInputRaw in MaterialTemplate.usf to make this global. This means less control ofc. Making a material function is probably the best way.

For people with this issue, you can check for MSAA with a custom material node using View.NumSceneColorMSAASamples

I also noticed that it seems to work pretty well with MSAA 4x now without any changes. This is also mentioned in the CustomAlpha2Coverage function in BasePassPixelShader.usf . It says todo: support non 4xMSAA as well. So it seems something is moving forward(no pun) there. :slight_smile:

Best Regards

15

Sadly, the workaround does not work anymore in 4.16.

Are there any news on another fix ?

16

This is a workaround to help with the visual banding that appears when using MSAA and Alpha to Coverage, but perhaps it will also help with the masking issues here?

To get a result closer to the deferred renderer, you can make your OpacityMask input into a steeper gradient. For example if you have an OpacityMaskClipValue of .33, you can do a Mul with 5 and then Subtract (.33 * 5). This will make the OpacityMask gradient steeper, pushing the translucent bands closer together, but keeping the value .33 in the same spot.

There are no updates to this issue as of now, but it is on our roadmap to be improved.

Thanks,

H.