Enable gltf crate KHR feature flags so models with extensionsRequired render - #1

Thanks for glimpse — it's the only current, purpose-built glTF thumbnailer I could find for Windows 11, and the software rasterizer is a genuinely good call.

The problem

The gltf crate gates each KHR extension behind a cargo feature, and rejects any glTF whose extensionsRequired lists an extension it wasn't compiled with:

Validation([(Path("extensionsRequired[0] = \"KHR_materials_unlit\""), Unsupported)])

Since Cargo.toml declares gltf = "1.4" with default features only, any model marking KHR_materials_unlit as required fails to load entirely.

The lenient fallback in load_from_bytes doesn't rescue it — gltf::import_slice fails, then gltf::Gltf::from_slice runs the same validation and fails identically, so no thumbnail is produced at all rather than an untextured one. load_from_path has no fallback, so it surfaces as a hard error there too.

This is common in the wild. Kenney's blocky-characters, retro-fantasy-kit and retro-urban-kit all mark KHR_materials_unlit as required. Note that models listing it in extensionsUsed only (e.g. furniture-kit, nature-kit) load fine today — it's specifically the extensionsRequired list that's fatal.

The change

One line, enabling the flags. No code changes needed — the existing material handling already reads base color and textures correctly once the document parses.

Measurements

Tested over 99 real GLB files — 86 Kenney models spanning 44 kits, plus 13 from a personal project — driven through renderer::render_thumbnail:

The one remaining failure requires KHR_mesh_quantization, which the gltf crate doesn't support and has no feature flag for. That one looks unfixable without upstream work in gltf-rs.

All 110 existing tests pass. Cargo.lock is unchanged by this — the features resolve within gltf-json, so the dependency graph is identical.

Not included here

While testing I also found that external-texture models (Kenney kits reference a shared Textures/colormap.png) render as untextured gray via Explorer, because the shell prefers IInitializeWithStream and stream init has no directory context to resolve the URI from. Declining that interface so the shell falls back to IInitializeWithFile takes those from gray to fully textured.

I've left that out of this PR — it trades away process isolation and feels like it should be your call, likely an installer option rather than a default. Happy to open it separately if you'd want it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jv8DyjXuNjQBrCeRnBGDPE