Depth API prevents use of content with floor-level features/detail

[benferns]

Description

This is a Scene Viewer bug, but I cant find another bug reporting area for that specific project.

When viewing content that rests on the floor on devices with Depth API support, the objects will phase & flicker through the floor plane due to inaccuracies in depth estimation.

Live Demo

https://glitch.com/edit/#!/join/686693d2-b5f1-468c-8dbb-8fd595e3496c

Version

• model-viewer: vX.X.X (all)

Browser Affected

• [x] Chrome
• [ ] Edge
• [ ] Firefox
• [ ] IE
• [ ] Safari

OS

• [x] Android
• [ ] iOS
• [ ] Linux
• [ ] MacOS
• [ ] Windows

[benferns]

As far as solutions - I feel like replacing tracked planes' depth information with definite values would be possible, but massively complex once you start introducing more than the 'floor' (the single lowest tracked plane).

A quick fix would be to have the option to disable depth API occlusion at start (since the user can do the same via the UI, it shouldn't introduce too many side-effects specific to the toggle).

[elalish]

Indeed, the depth is not particularly accurate, which is why Scene-viewer fades out with depth. Have you tried webXR mode? It doesn't do depth occlusion. I'd also be interested in knowing what makes you choose one mode over the other. @tpsiaki regarding the depth feedback for scene-viewer.

[benferns]

Hi elalish - in my particular use-case I can't use model-viewer's WebXR mode as I'm generating an intent:// link via an API that needs to drop directly into the AR mode without an intermediate webpage or showing any url to the user (as its for a commercial product where the brands do not want users to see the underlying service, or to add webpages to their site). This will be reached via non-website routes like QR codes, email newsletter links etc.

In terms of preferring scene viewer in other cases:

I have tested a WebXR implementation for other use-cases when launching AR on Android from a webpage, but we've received some feedback around the rotation behaviour that's stopped us from proceeding so far - in most of our user-testing users try to use two fingers to rotate, and a single finger to drag. Since models' bounds generally fill the frame they never discover the single-finger rotation.

We've also had a case where a model file's roughness looked very different visually between scene viewer and model viewer, but that may just be a poorly prepared gltf. Unfortunately we didn't chase down the issue to confirm as we had already received the rotation feedback and decided not to proceed. I can dig up the model if it would be of use.

I suspect I'll end up on model-viewer's WebXR implementation eventually (as the end goal is a universal UX & feature-set for iOS/Android AR quicklooks, and model-viewer is extensible in a way that works for that) but we're a very new startup with a considerable roadmap between here and there!

[sercanov]

Hi all, we're also having hard times with Depth API. I wish there were a parameter to disable Depth API in Scene Viewer. In my experience, Scene Viewer were more stable than WebXR so we choose to use it.

[elalish]

@60days Thank you for the detailed feedback! I'll make sure to get two-finger rotation into webXR shortly. There is a known issue in scene-viewer where shiny objects appear too rough due to the way ARCore calculates AR lighting.

[benferns]

I'm closing this as I believe the flag disable_occlusion=true (on the intent) should prevent the issue

[PavelKhabusov]

You can use Depth API's Occlusion Depth Bias from demo scene SceneAPIPlacement