Viewing this model in AR mode on Android causes Scene Viewer to crash

[chadt-3dc]

I have pinpointed the issue to the fact that this model has no vertices above the Y=0 ground plane. If I create another version of the file with all the vertices shifted a tiny amount above the Y=0 plane, or a version with the transform itself shifted up a tiny amount, then it no longer crashes. I think it's because it's using only the mesh data found above the Y=0 plane to calculate the near and far plane values for the camera, but since there isn't any, it uses near=0 and far=0 and then Filament crashes.

04-21 13:46:24.330 E Filament: reason: Camera preconditions not met in setCustomProjection(): near = far = 0
04-21 13:46:24.485 F libc    : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL)

Light.zip

[smirnov-artur]

Your diagnosis matches where the crash actually lives, and it is worth being explicit about the consequence: this cannot be fixed from model-viewer, so it is not worth waiting on a release here.

Filament: Camera preconditions not met in setCustomProjection() is Scene Viewer's own renderer. Scene Viewer is a separate Android app, and model-viewer hands it nothing but a URL (features/ar.ts):

const intent = `intent://arvr.google.com/scene-viewer/1.2?${...}`;

It downloads and parses Light.glb itself, in its own process. No attribute, parameter or JS call on the <model-viewer> element reaches the code that computes those near/far values, which is why the only lever you found is the file.

One thing to know so you don't wait for a recovery that isn't coming

There is a fallback path, but it does not cover a crash. isSceneViewerBlocked is only set here:

const undoHashChange = () => {
  if (self.location.hash === noArViewerSigil) {
    isSceneViewerBlocked = true;
    ...
    console.warn('Error while trying to present in AR with Scene Viewer');
    console.warn('Falling back to next ar-mode');
    this[$selectARMode]();

That fires when Scene Viewer declines to open and the browser comes back with the sigil hash. Once it has launched and then aborts inside Filament, the page never sees it — so no ar-mode fallback runs and the user just lands back on a dead AR button.

What actually reduces the exposure

ar-modes defaults to webxr scene-viewer quick-look, and the selection loop takes the first supported entry:

if (value === 'webxr' && IS_WEBXR_AR_CANDIDATE && !isWebXRBlocked &&
    await this[$renderer].arRenderer.supportsPresentation()) {
  arMode = ARMode.WEBXR;
  break;
}

So on Android devices with WebXR available, Scene Viewer is already skipped and the crash never happens. The affected population is specifically Android devices that fall through to Scene Viewer. Dropping scene-viewer from ar-modes removes the crash outright, at the cost of AR on those devices — a trade worth measuring against your own analytics rather than assuming.

Make the asset fix deterministic rather than per-model

Nudging vertices by hand does not survive a re-export. Since the trigger you identified is geometry that sits entirely at or below Y=0, it can be caught in a build step — compute the bounding box, and if max.y <= 0, translate the scene up by a small epsilon before writing the file. glTF-Transform will do this over a whole asset directory, so new exports can't quietly reintroduce it.

That also gives you a check to run against your existing library, which is probably worth doing once: any other model authored the same way is a crash you have not hit yet.