WebXR mode broken on Vision Pro with A-Frame 1.6.0

[JL-Vidinoti]

Description:

In WebXR mode (VR) using the Vision Pro, the gltf-model do not appear correctly. The ordering of the elements is wrong. It was working fine with version 1.5.0 but the bug appears with the latest 1.6.0 version.

• A-Frame Version: 1.6.0
• Platform / Device: Apple Vision Pro
• Reproducible Code Snippet or URL: https://silver-fog-earl.glitch.me/ (https://glitch.com/edit/#!/silver-fog-earl?path=index.html%3A29%3A37)

In browser mode, it works properly.

The issue appears in VR mode

[mrxz]

Sadly not in possession of an AVP to test. @dmarcos can you reproduce the issue?

The strange thing is that even when meshes are sorted incorrectly, the depth buffer should still prevent outcomes like this. For completion sake:

• Are there any errors/warnings logged in the console?
• Does the issue also happen without the gltf-model or only with the gltf-model?

Can't immediately think of a change in A-Frame that could cause this. I suspect that it's due to a change in Three.js. If you could git bisect between the v1.5.0 and v1.6.0 tags that would be awesome.

A stab in the dark, but could you try adding renderer="stencil: true" to <a-scene> and see if that changes anything?

[JL-Vidinoti]

I have one error appearing in the console but I don't know if it's related.

I only observed the issue with the gltf-model but I did only few tests. However, while trying the code snippet shared earlier, I observed that the objects were disappearing when I was looking up. See recording below.

https://github.com/aframevr/aframe/assets/35372626/d0546a4b-2f5b-4134-a91d-393536eb26a2

I tried renderer="stencil: true" but the same problem occurs.

[dmarcos]

Can you try a different simpler gltf model? Could be the shaders / materials of that model

[arpu]

only idea is the soring change from https://github.com/aframevr/aframe/pull/5341

[mrxz]

From the video it's clear that something is up with the depth buffer. It's as if it isn't being used, but the helmet seems fine, so perhaps it's somehow cleared/invalidated after each draw. The sorting is behaving as you'd expect, the closest objects are drawn first. Looking up most likely causes the sky to end up being drawn last, which makes the rest disappear.

Someone with an AVP really just needs to do a git bisect and we'll know the exact change causing this.

[JL-Vidinoti]

I found the commit causing the issue: https://github.com/aframevr/aframe/commit/a6ec41728d643b54520ff7518bcd298bc70c1e4c

I also did some more tests and it is not related to the gltf-model. The standard scene looks like that with the Vision Pro: But it should look like that:

[mrxz]

@JL-Vidinoti Thanks for digging into this. That commit most likely causes the AVP to be considered mobile by A-Frame. The puzzling part is still how this in turn causes these weird rendering issues (as even on mobile devices things should just work).

One thing that differs is that antialiasing is disabled by default for mobile devices. Could you try if the problem persists when you explicitly enable antialiasing: <a-scene renderer="antialias: true">?

[JL-Vidinoti]

Good catch! It works by enabling antialiasing.

[dmarcos]

Thanks for investigating. Much appreciated. This means that isTablet isIpad return true on AVP after https://github.com/aframevr/aframe/commit/a6ec41728d643b54520ff7518bcd298bc70c1e4c ?

We gotta correct that so antialising is enabled by default again on AVP

Gott understand why lack of antialising affects the rendering order but probably need to be handled in a separate issue.

[vincentfretin]

If that helps, there is this link that was shared on discord a few days ago to detect if you're on Vision Pro: https://github.com/danrossi/ios-detection-utils/tree/main

[Utopiah]

Also had problems with models on Vision Pro that I didn't encounter before, wondering if it's related to Vision OS 1.2 rather than an AFrame update.

[dmarcos]

Vision OS 2 has been released. Is this still a problem?

[Utopiah]

Tried on Vision OS 2 today and everything worked as expected, including the initial Glitch shared to open the issue.

IMHO it can be closed unless there is something else specific.

[dmarcos]

Thanks for testing @Utopiah Closing and can reopen if necessary