glTF Exporters

**Owner:** Alex
---
## glTF Exporter

**Guidelines**: tree-shakeable, WebGPU-only, pixel-parity with BJS

**P0 - Must do**
- [ ] Scene and node hierarchy
- [ ] Lights and cameras
- [ ] Geometries and meshes
- [ ] Materials
- [ ] Node animations
- [ ] Skeletons and skeletal animations
- [ ] Extensions
- [ ] Bundle-size ceiling tests
- [ ] Visualization tests — do they match the golden screenshots from BJS?

P1 - Should do

- [ ] Explore improvements to exporter's internals (see P2)
- [ ] Bring back any improvements to BJS

P2 - Nice to have

Dusting off some old ideas. Capturing them here because maybe they can inform early architecture decisions.

- [ ] Explore better opt-in architecture for post-processes (Draco, meshopt, KTX2/Basis)
- [ ] User-defined, custom extensions
- [ ] Run export off the main thread by default (Web Worker)
- [ ] Stream large exports instead of building the whole file in memory (that async token streaming API?)
- [ ] Transform data on GPU before reading it back to CPU (compute shaders)

Open questions
Some things to answer or consider before diving in, organized by what they impact.

**Scope**
- [ ] The serialization surface area to cover — just glTF? Or also .babylon, USDZ, screenshots, etc.
- [ ] Define the target exporter architecture — how much can/should change vs. a straight port?

**Design**
- [ ] Clarify cross-engine portability — how much can/should Lite outputs be parseable by BJS? Edge cases?

**Implementation**
- [ ] Double-check plans for geometry and textures — do we need to read these back from GPU now or is it business as usual?