Babylon Native Lite (Same Pillars)

[Created by Copilot on behalf of @bghgary]

**Owner:** @bghgary and BN Team

Subproject for bringing Babylon Lite to Babylon Native while preserving the same pillars (small footprint, WebGPU-modern shape, tree-shakable, pixel-parity with Babylon.js).

We are currently in unknown-unknown territory. The goal of this initial phase is to **prototype enough to produce concrete data** to inform the next round of decisions. Evolving design notes (not yet a real plan) live at:

[BABYLON_LITE_PLAN.md](https://github.com/bghgary/BabylonNative/blob/bghgary/babylon-lite-plan/BABYLON_LITE_PLAN.md)

## Prototype focus sprint — week of June 15

The native team is running a one-week prototyping focus sprint starting **Monday, June 15**. Each engineer takes one possible direction for Babylon Native Lite and builds a prototype in parallel, aiming to fail fast and exit the week with a **stack-ranked list of the technical approaches** plus explicit recommend / don't-recommend calls. Each prototype produces comparable data (below) so the approaches can be ranked against one another.

The current leading hypothesis is the **frame graph as the seam** (S0, #176) — but it is not assumed; several branches deliberately diverge from it (e.g. the Dawn / WebGPU branch runs WebGPU *on* native as a correctness reference) so it can be tested against alternatives.

Approaches and owners (tracked as sub-issues):

- **Frame graph (S0)** — @bkaradzic-microsoft — #176
- **Dawn / WebGPU (S1)** — @CedricGuillemet — #177
- **Native / no-JS, transpiler (S7)** — @bghgary — #178
- **CPU task-graph / flow-graph (S9)** — @ryantrem — #179 *(non-critical-path)*
- **Lite native twin + bgfx implementation layer** — @SergioRZMasson — #318

Each prototype renders the same minimal scene and reports, compared against Lite-on-web on the same authoring inputs:

- **Pixel parity** — MAD vs Lite-on-web golden.
- **Frame rate / frame time** — average + 99th-percentile, with a JS-vs-native breakdown.
- **Binary size** — total Windows output, per component when feasible.
- **Memory** — resident, GPU, peak.
- **JS↔C crossing count and cost per frame.**
- **Effort / complexity**, plus a concrete list of pain points (e.g. where Lite eagerly creates GPU resources).

This is the first phase of investigation. The data and findings here will feed further discussion — and likely additional prototyping rounds — before we converge on a real plan.