processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.74k stars 3.34k forks source link

mobile webgl image decals #4183

Open danielemichieletto opened 4 years ago

danielemichieletto commented 4 years ago

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

Nature of issue?

Most appropriate sub-area of p5.js?

Which platform were you using when you encountered this?

Details about the bug:

welcome[bot] commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.