Lighting Artifact in 4.20 (regression)

After upgrading to 4.20 we’re getting bright lighting artifacts on the edges of some objects. See screenshots for comparison to 4.19. There’s some pretty severe flickering as well; I can provide a gif or video if necessary.

The light in question is a fully dynamic directional light facing the camera (it’s also generating the light shafts in the images). Tried changing it to a stationary light but that didn’t have any effect.

None of the light settings have any effect except Specular Scale; when modifying that the issue is still visible but not as bright unless the value is set to zero.

4.19

4.20

Hello,

We’ve recently made a switch to a new bug reporting method using a more structured form. Please visit the link below for more details and report the issue using the new Bug Submission Form. Feel free to continue to use this thread for community discussion around the issue.

https://epicsupport.force.com/unrealengine/s/

Thanks

In 4.19 did this light have a non default value in the MinRoughness property?

Yes. In this particular scene the MinRoughness was set pretty high - 0.8. It seemed from the source changes that SpecularScale is the new variable to modulate this, but any value that displays anything at all still has overbright pixels on the edges which flicker as the mesh animates.

EDIT: I did go back and check 4.19 with MinRoughness set to the default and it has a similar result to 4.20. So I guess the issue for us is that SpecularScale doesn’t seem to be able to replicate the results of the old setting.

The new SpecularScale should only be used to turn it on/off with 4.20 according to the docs. Try using the new parameter ‘Soft Source Radius’ with a high value (50 or so to test) on the affecting light to see if that works for you.

It’s a directional light so it has SourceSoftAngle instead. I had tried that, but using the editor’s slider interface which goes from 0 to 5 and it had no effect. After getting to someone from Epic via the bug report form we finally established that the actual value required to emulate large MinRoughness values is actually more like 50. Unfortunate that the editor’s guidance is wrong, not to mention the lack of data conversion when upgrading, but at least it’s resolved for us now.