Putting a GSoC 2026 proposal together for the glTF export request in mapeditor/tiled#2741, and I’d rather get pushback on a few design calls now than guess wrong.
Plan in one paragraph: one glTF mesh per `TileLayer`, one primitive per tileset used in that layer. Each tile is a quad with UVs from the atlas (margin, spacing, tile offset). Vertex positions come from the existing renderer math so ortho / iso / hex all go through code that already works. Animated tiles ride along as `extras` so we don’t bake in one runtime’s animation model. Scaffold PR is #4485 on my fork — `write()` currently returns `false` with a “not implemented” error, deliberately, while the design is still up for argument.
POC writer against cgltf is at GitHub - PrateekSingh070/tiled-gltf-poc · GitHub — single-quad C demo plus a 2×2 ortho tile grid in C++ using the real `tileToScreenCoords` and atlas-UV math. Both validate clean.
Three things I’d actually like opinions on:
1. **Collection-of-images tilesets.** Pack into a runtime-generated atlas at export (one `baseColorTexture` per primitive, cleaner downstream) or emit one material per source image (simpler, no rect-packer in the export path)? I’m leaning toward packing but the blast radius of a packer bug worries me.
2. **Object layers.** Plan is glTF nodes with position / shape / custom properties in `extras`, and tile objects as textured quads. Anything you’d want represented differently?
3. **Export options UI.** Embed-vs-external textures, `.glb` vs `.gltf`, include object layers — is there an existing per-format options hook in the plugin API I should be using, or should I lean on file extension and glTF conventions?
Pushback is more useful to me than encouragement. If any of the above is “don’t do that”, I’d rather know before May.
-– Prateek (GitHub: [PrateekSingh070]( PrateekSingh070 (Prateek Singh ) · GitHub ), forum: Prateek7)