Weird artifacting on textures generated on an iPad running iOS <15

My artist made some lighting changes recently and afterwards we started noticing very strange artifacting on some iPads.

Here is the image without the artifacts (iPad 9th gen, iOS v15.0 on browserstack)

For reference, this is a live view through an orthographic camera.

Here is the exact same thing on an iPad Pro 11 running iOS v14.5:

As far as we can tell this affects most iPads running an iOS version less than 15.

To complicate things, it’s extremely difficult to differentiate between a Macbook and an iPad running iOS >=13 so even if we can come up with an alternative lighting scheme I’m not sure exactly how I’m going to detect affected devices.

Could you give us some more details on what it means lighting changes?

What does it look like on desktop?

One other thought just to add to this… Are you using Browserstack by chance? That looks like the Browserstack UI from the screenshots. My company uses browser stack for general web development but when we started doing WebGL work we tried using it as we always had and noticed a lot of inconsistencies coming from it that cannot be replicated on phones in real life. For example on browser stack about half the time I use a galaxy s20+ I get odd artifacting that isn’t real. The bug list goes on and on so if that is what you’re using, make sure you’re getting the issue on a physical phone.

1 Like

Are you sure this is iOS related and not model related? 9th generation iPads have an sRGB retina display while iPad Pro 11 uses DCI-P3 liquid retina display, so maybe it’s just down to different color gammuts of the models.

Hi, I’m the artist working with Quincy.

The main changes to the lighting were increasing the shadow Distance and VSM Blur Size so the shadows weren’t harsh on both our main and fill directional lights.

In testing, if we decreased the blur size on the fill light we lost some visual quality and the artifacts seemed to go away, but if we dropped it too much we get the artifacts on desktop. Currently desktop looks fine.

@Katy Could be related to this? https://github.com/playcanvas/engine/issues/4022

1 Like

I am using browserstack to test this out of necessity but I’m responding to a client who is having the exact issue on a physical device.

There does appear to be a pretty drastic difference between the previous engine version (1.50.2) and the current engine version (1.51.7)

Here is the current engine version:

Here is the previous one:

You can tell that the bug is still present in the old version but it has quite clearly gotten worse.

Here it is on the prerelease candidate (1.52.2). Does not appear to be significantly different than the current version.

I’ve received confirmation that this issue is not present in our app on Windows 11.

At this point, I would look at creating a smaller project to repro this issue and make it a lot easier to see the differences across platforms. Is that something you would be able to provide and we can try to track down the commit.

The alternative here is to use the lightmapper here instead of dynamic lights to get a render with AO and softer shadows https://playcanvas.github.io/#/graphics/lights-baked-a-o

I’m not sure I understand the scene … all I see is what seems to be a white background image with lines, and some windows on top. What is casting and what is receiving shadows here?

Ok here’s the pipeline:

I generate a 3D garage door based on some input. This is composed of a bunch of small pieces that I then stretch as appropriate to get the correct size.

Then I line up an ortho cam with the front of the door:

I take a screenshot through that ortho cam and save the result to a texture. The texture is then applied to a dynamic mesh plane which is then placed in front of another plane with a picture of a house on it:

The thing that keyed us into the issue was that the client was getting these artifacts on the final scene view. This has happened before on old iDevices (and @yaustar helped me resolve it, I believe the issue in that case was using too large, non-power of two textures) but this time it appears that the distortion is occurring in the live view from the capture cam rather than just in the resulting textures.

I don’t think using baked light is a viable option because this is all dynamically generated.

I can look into attempting a repro project.

You can rebake the lighting at runtime using the lightmapper in PlayCanvas

1 Like

Ah, good to know. That may work nicely then

I was immediately able to get shadow banding of this type on iPad iOS 14 just by copying our lighting rig over to a blank project and pointing an ortho cam at a white plane. Here is the project.

It doesn’t seem to be as bad as we’re seeing on the garage doors, I’m not sure why.

Interestingly I’m also seeing the effect in the editor for some reason if I rotate the plane to specific angles

The lighting rig contains 2 active lights:
image

The banding appears to be coming from the Fill light. Here is that light isolated:

I’m also seeing the banding on my pc, although it is MUCH lighter, to the point where I can only really see it on one of my monitors:

Here is the lighting configuration

I’ve tried tweaking basically all of the settings with a browserstack open on my second monitor, and I do get varying results… but nothing is really quite right. Also some settings appear to make the effect more or less pronounced in the editor. For example setting VSM blur size to 8 makes it extremely apparent:

And here it is in the launch tab:

At this point I’m doubtful that there is any lighting configuration that will actually eliminate this problem on all devices. It seems to be a severe bug in the way VSM blur is applied.

@yaustar @mvaligursky I urge you to fork the project and try this for yourself.

1 Like

I’d probably just suggest to use PCF5 shadows instead of VSM, as VSM is a bit harder to get working consistently. At least till we have time to investigate and improve it.

2 Likes

I linked this thread to the engine issue on this topic

1 Like

You can also try bumping the VSM to 16-bit. I’ve previously had more consistent results with VSM shadows using 16 bit or PCF5x5.

1 Like