Materials for Ground Primitives don't work for small areas on newer mobile devices

[likangning93]

Sandcastle

Increasing offset to larger than 1.0 switches to spherical coordinates, which mostly works other than some depth precision issues.

Related: #6735

[EDIT] for anyone new to this issue, Cesium uses the materials-on-GroundPrimitives codepath when available for batching colored GroundPrimitives, which is why on some newer mobile platforms corridors on terrain won't work bu on earlier mobile platforms without depth texture support they will work.

[likangning93]

I think it's a batch table problem.

Here's a Sandcastle with a stripped down version of the shader that just computes texture coordinates using planar distances.

Here's the same Sandcastle, but with all batch table reads replaced with hardcoded values.

The former computes texture coordinates very incorrectly on iPad.

[likangning93]

Pretty sure it's because of how high/low values are being encoded.

Sandcastle that just passes a diff between batch table read and expected from VS to FS.

Results on Desktop:

On iPad:

Haven't binary searched yet, but diff here is in the range of 980,000 to 990,000 in the R channel on our A9X iPad Pro.

[likangning93]

At @bagnell's suggestion, tried disabling floating point textures in the batch table which results in the same thing happening on Desktop. So that's interesting. The iPad should have float texture support though.

[likangning93]

Maybe the iPad is actually doing the same packing thing under the hood, which might also explain the depth texture problems... that is very bad.

Regardless, I'll open a PR soon adding a check for float texture support.

[likangning93]

BTW on Desktop, using our float packing code, the diff doesn't seem to be as bad as it is on iPad.

[likangning93]

^

[likangning93]

^ that was on Windows Nvidia, it's less on Linux/Intel which is interesting.
Maybe instead of requiring float textures we can come up with something more clever to reduce the range of the floats getting packed.

[EDIT] that would also theoretically work for iPad, but we'd have to use feature detection to force something, which is never super satisfying. But it's better than just throwing in the towel!

[likangning93]

So I tried:

• logarithms
• square roots
• inverses

All of these seem plausible on desktop but don't produce useable results on the iPad, so we probably have to scrap the range reduction idea.

[likangning93]

A good thing to have might be minimal proof of the iPad's float texture misbehavior, it'll at least help if we try to report this problem to Apple.

[likangning93]

I think I have to put this aside for a couple days at least, here's a few more notes for picking this back up:

last resort

• spherical texture coordinates work fine, they just won't look good for small areas
• we can add a fallback for this if nothing else works

Two more ideas to try

• alternate packing method - go so far as to encode each float into many integer groups of sigfigs

  • -6123456.789 -> uint8: [194 or something, 23, 45, 67, 89].
  • probably lots of caveats on why you wouldn't want to do this for generic floats, but for us we know that they're distances in meters, equal or lower order of magnitude as Earth radius in meters, and only need accuracy to 2, maybe 3 decimal places
  • this is also just a fallback, Apple may yet fix this too

• tweak Cartesian4.packFloat and czm_unpackFloat specifically for iOS

  • observe that there's a "bias" in here
  • these functions already behave differently on Intel/Linux and Nvidia/Windows
  • maybe we can tune for iOS

[likangning93]

Pointed out by @mramato: https://www.khronos.org/webgl/public-mailing-list/public_webgl/1703/msg00036.php

It's nice to not be alone

[likangning93]

A lot of users have been running into this and #6735 lately, because Cesium currently uses materials for GroundPrimitives to batch corridors when it detects the required extensions and many users consider corridors to be a legacy "fallback" for polylines on terrain.

For now we should disable both polylines on terrain and materials-on-GroundPrimitives on mobile, this way any legacy fallbacks will still work.

[Spec1alFx]

I'm one of this users;
just one detail: I found that clamped to ground polygons (corridors, rectangles and so on) are not displayed on modern devices BUT are working on my old Galaxy Note 3.

Question: polylines on terrain are a very useful (and wanted) feature and are working on mobile (although with some graphical glitches when camera is too near or too far). For my use cases it would be better to be free to choose between polylines on terrain and corridors than disable the first ones at all.

Thank you!