WebGPU Engine Fails to Render Standalone Static Meshe

Bugs
1

# Bug Report: `@babylonjs/lite-compat` WebGPU Engine Fails to Render Standalone Static Meshes

## Environment

* **Library:** `@babylonjs/lite-compat`

* **Version:** `^1.16.0-preview`

* **Engine:** `BABYLON.WebGPUEngine`

* **Material Used:** `BABYLON.StandardMaterial`

## Description of the Bug

When using `@babylonjs/lite-compat` with the WebGPU engine, standalone static meshes created via `BABYLON.MeshBuilder` (e.g. `CreateGround`, `CreateBox`) or standard static geometry completely fail to render on screen.

The meshes are successfully added to the scene, their bounds are calculated correctly, materials are loaded properly, and `mesh.alwaysSelectAsActiveMesh = true` does not force them to appear. The WebGPU render pass silently ignores these meshes, meaning they never make it to the screen.

The *only* geometry that successfully renders in this configuration are meshes that utilize **Thin Instances** (`thinInstanceSetBuffer`).

> [!NOTE]

> Reverting the project to standard `@babylonjs/core` immediately fixed the issue, confirming that the bug is isolated to `lite-compat`'s rendering pipeline logic for WebGPU.

## How to Reproduce

1. Initialize `BABYLON.WebGPUEngine` and load a scene using `@babylonjs/lite-compat`.

2. Create a basic standalone static mesh (e.g. a ground plane).

3. Apply a standard material (e.g. `BABYLON.StandardMaterial`).

4. Attempt to render the scene. The mesh will be completely invisible.

**Code Example:**

```javascript

// This fails to render in lite-compat

const debugGround = BABYLON.MeshBuilder.CreateGround(“debugGround”, {width: 50, height: 50}, scene);

const debugMat = new BABYLON.StandardMaterial(“debugMat”, scene);

debugMat.diffuseColor = new BABYLON.Color3(1, 0, 0);

debugGround.material = debugMat;

```

## The Workaround

To bypass this bug, developers must currently trick `lite-compat` into treating all static standalone geometry as instanced meshes by explicitly assigning a single identity matrix thin instance.

By applying the following workaround, the standalone meshes are successfully picked up by the draw call and rendered to the screen:

```javascript

// Workaround: Inject a single thin instance to force the mesh to render

const identityMatrix = new Float32Array([1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,1]);

mesh.thinInstanceSetBuffer(“matrix”, identityMatrix, 16, false);

mesh.thinInstanceCount = 1; // Required for the buffer to be respected

```

## Expected Behavior

Standalone static geometry created via standard APIs like `MeshBuilder` should render normally out-of-the-box on WebGPU without requiring manual assignment of thin instance buffers.

4

Let me add @ryantrem to the thread as he is the lite-compat daddy

5

Looking…

6

Thanks for the report! I tried to reproduce this on @babylonjs/lite-compat@1.16.0-preview with the WebGPU engine, and standalone meshes render fine for me in every variation I tried:

  • MeshBuilder.CreateGround + a StandardMaterial created before the render loop starts
  • the same thing created after runRenderLoop (new mesh and a brand new material at runtime)
  • diffuseColor only (no emissive), both with and without lights in the scene

We also have a parity scene in CI that is essentially exactly your snippet (a StandardMaterial mesh plus a ground plane), and it’s green.

So I don’t think standalone meshes are broken across the board - something more specific in your setup is triggering this. Two notes that might help narrow it down:

  • mesh.alwaysSelectAsActiveMesh and mesh.thinInstanceCount don’t exist in lite-compat at all, so setting them is a silent no-op. They aren’t telling you anything either way.
  • The fact that thinInstanceSetBuffer makes the mesh appear is actually a useful clue: it moves the mesh onto a different material/pipeline family. That points more at how the material or scene is being set up than at the draw path itself.

Any chance you could put together a minimal repro? A small repo, or even a single stripped-down page that actually shows the mesh disappearing, would let me track this down quickly.

If the project isn’t shareable, the scene setup order alone would help a lot:

  • when the mesh is created relative to engine/scene start
  • whether a ShadowGenerator is involved
  • whether that material is shared with any other mesh
  • whether anything else (post-process, render target, frame graph) is in play

Happy to dig in as soon as I can see it fail.