mobile webgl image decals

[danielemichieletto]

On iOs mobile devices, 2 images applied on very close surfaces are displayed intermittently.
On Android and desktop is OK

Nature of issue?

• Found a bug
• [X ] Existing feature enhancement
• New feature request

Most appropriate sub-area of p5.js?

• Color
• Core/Environment/Rendering
• Data
• Events
• Image
• IO
• Math
• Typography
• Utilities
• [ X] WebGL
• Other (specify if possible)

Which platform were you using when you encountered this?

• [X ] Mobile/Tablet (touch devices)
• Desktop/Laptop
• Others (specify if possible)

Details about the bug:

• p5.js version: 0.9
• Web browser and version: Safari app and Chrome app
• Operating System: iOs 13.2.3
• Steps to reproduce this:
  https://editor.p5js.org/daniele.michieletto/sketches/jSySszzQ4

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.

[aferriss]

This looks like maybe a z-fighting issue to me. I took a recording on an iPhone XR with safari 13.2.3

https://www.dropbox.com/s/501tl7jo6e2rnyq/RPReplay_Final1575658616.MP4?dl=0

Without looking into the rendering code, I do seem to remember apple limiting the depth buffer precision on mobile devices. It might be possible to write a custom shader that just adds a teensy little value to the gl_Position.z in the vertex shader to get around this specific case, but that is not a general solve for the library.

It could also be that highp precision is not available on all mobile gpu drivers, which would result in the rendering glitchiness.

I'm not sure what p5 is using for the near and far clip values of it's rendering pipeline but it might be worth testing narrowing the range to something a bit smaller, which should have the effect of giving more precision in the depth buffer.

[stalgiag]

Yes this seems like a depth precision issue. Not necessarily something we can fix on our end, but we can make it easier to identify these problems and work with depth precision, near, and far values.

I think that the current way of selecting default near and far clipping values might be a bit too opaque. It is automatically calculated based on size of canvas and field of view. This is good in some scenarios but I have seen this create confusion, especially when someone is making a windowWidth/windowHeight sketch. In different sized windows, this can cause sketches to have unexpected overlap or occlude near or far objects.

Perhaps we should give near and far non-calculated default values, and figure out a way to warn people when they may be drawing outside of it? This second part seems a bit involved, maybe part of the FES.