Die Dubiose Dev

Bevy glTF Considerations

Caitlin Sar Campbell — Sat, 07 Mar 2026 00:00:00 +0000

The situation at hand.</h1>
The amount of work that has been put into the Bevy glTF system is clear and evident. There is a ton of functionality that works really well and helps the engine shine.</p>
In working on my game and continuing to learn the Bevy codebase, there is an issue that I think, while not threatening now, will only continue to grow into a larger and larger problem as time goes on.</p>
This is the state of the `gltf-rs</code> dependency that Bevy uses in the bevy-gltf</code> crate.</p>`
`This crate is not well maintained, to the point where the same issue has been submitted multiple times over the years.</p>`
2023 - https://github.com/gltf-rs/gltf/pull/392</li> 2025 - https://github.com/gltf-rs/gltf/pull/456</li> 2026 - https://github.com/gltf-rs/gltf/pull/467</li> </ul> All three of these are for the same issue, adding KHR_texture_basisu</code> support, and in my opinion all three were/are clean implementations against the existing gltf</code> codebase.</p> If you look at the outstanding PRs</a>, most of them are for adding one or another of the Ratified Khronos Extensions </a>.</p> This is where the fundamental issue arises. While these extensions are not part of the core glTF 2.0 specification, they are de facto needed in order to use glTF as a modern 3D asset standard, particularly where glTF/GLB is the primary and preferred asset format.</p> As Bevy becomes more and more widely recognized as a game engine, it will become stranger and stranger that the only real options for textures are JPEG and PNG, both with their own issues and non-native GPU deficiencies.</p> Even worse, in my book, is telling current and future Bevy developers that "Bevy sort of hacks in KTX2 texture support in glTF files, but you need to use a special tool that turns your compliant glTF file into a non-compliant one BUT IT WORKS IN BEVY!"</p> What should we aim for?</h1> Before continuing to consider resolutions, I think considering what would be desirable is worth doing.</p> Long Term</h2> From a developer perspective, the ideal goal would be to make the glTF/GLB experience a first-class one.</p> The developer should be able to use glTF/GLB files without fear, without worrying about compatibility or the need to hack things in, in the same way that a Unity developer imports .unity</code> assets knowing things will go smoothly.</p> Technologically speaking, I think this means we aim for FULL compatibility with all ratified Khronos extensions</a>.</p> This is less daunting than it may seem. We already handle a good amount of these, and just need to parse the glTF JSON to hand it off to the relevant existing Bevy code.</p> Others are already in progress.</p> Others will need new code in Bevy or elsewhere.</p> In addition, I would propose that we consider adding selected vendor extensions including EXT_texture_webp</code> and EXT_texture_avif</code> (if we have AVIF support in the engine already). These are less important, but would lean into the first-class developer experience.</p> Short Term</h2> In looking at what level of expanded glTF support we see in other game engines, we see this:</p> Extension</th> Godot</th> Unity</th> Bevy</th></tr></thead> KHR_animation_pointer</code></td> X</td> </td> </td></tr> KHR_draco_mesh_compression</code></td> X</td> X</td> </td></tr> KHR_lights_punctual</code></td> X</td> X</td> X</td></tr> KHR_materials_anisotropy</code></td> X</td> </td> X</td></tr> KHR_materials_clearcoat</code></td> X</td> X</td> X</td></tr> KHR_materials_diffuse_transmission</code></td> X</td> </td> </td></tr> KHR_materials_dispersion</code></td> X</td> </td> </td></tr> KHR_materials_emissive_strength</code></td> X</td> </td> X</td></tr> KHR_materials_ior</code></td> X</td> in progress</a></td> X</td></tr> KHR_materials_iridescence</code></td> X</td> </td> </td></tr> KHR_materials_sheen</code></td> X</td> in progress</a></td> </td></tr> KHR_materials_specular</code></td> X</td> in progress</a></td> X</td></tr> KHR_materials_transmission</code></td> X</td> in progress</a></td> X</td></tr> KHR_materials_unlit</code></td> X</td> X</td> X</td></tr> KHR_materials_variants</code></td> X</td> X</td> </td></tr> KHR_materials_volume</code></td> X</td> in progress</a></td> X</td></tr> KHR_mesh_quantization</code></td> X</td> X</td> </td></tr> KHR_texture_basisu</code></td> X</td> X</td> </td></tr> KHR_texture_transform</code></td> X</td> X</td> X</td></tr> KHR_xmp_json_ld</code></td> X</td> </td> </td></tr> EXT_lights_image_based</code></td> X</td> in progress</a></td> </td></tr> EXT_mesh_gpu_instancing</code></td> X</td> X</td> </td></tr> EXT_meshopt_compression</code></td> X</td> X</td> </td></tr> EXT_texture_webp</code></td> X</td> </td> </td></tr> KHR_materials_pbrSpecularGlossiness</code></td> X</td> partial</td> </td></tr> Godot docs don't list supported and unsupported extensions, but looking through the source I found nothing missing.</a></td> </td> </td> </td></tr> Unity imports via glTFast</a></td> </td> </td> </td></tr> </tbody></table> I propose that, short term, we aim to be a superset of Unity, focusing on supporting the extensions they have that we don't.</p> Short term, we may consider adding EXT_texture_webp</code> as well, since this would be trivial once we decide on an approach.</p> Potential Resolutions</h1> There are several resolutions I could foresee. BUT the only resolution that I think would be actively harmful would be to continue to base bevy_gltf</code> on gltf-rs</code> without a long-term plan.</p> We should not pull a Warhammer 40k and build an empire around a slowly rotting corpse of a project. Not without a plan to lean less on the corpse at least.</p> Best Case - gltf-rs revival</h2> If we can revive the project, either through a maintainer of gltf-rs</code> becoming active or through the project adding a Bevy-vouched-for approver, this would be the best case.</p> With an understanding that the gltf-rs</code> project owners may have certain requirements, we could agree to only make changes that do not interfere with those requirements.</p> This requires some buy-in from the gltf-rs</code> owners, which may be impossible.</p> This would allow us to make these changes to benefit Bevy and the community as a whole.</p> Case 2 - gltf-rs fork</h2> Another option is for a group of people to maintain a fork of the existing project. It will be more work, but the crate is well documented and has a test suite that could be expanded to reduce future labor.</p> Here we could start by cherry-picking the relevant existing PRs, and we would be halfway done with our long-term goals.</p> The advantage here is that we could use upstream labor in our efforts to maintain the crate. The whole wider community benefits.</p> Case 3 - do raw glTF I/O in-house as part of bevy-gltf</h2> This is less bad than one might think. Right now we use gltf-rs</code> and wrap our "user space" GltfExtensionHandler trait</a> around it.</p> There are some existing extensions that are implemented in-house, namely khr_materials_anisotropy</code>, khr_materials_clearcoat</code>, and khr_materials_specular</code>.</p> I think this approach is valid. My primary concern here is that we are still wrapping the code around a slowly rotting corpse. My secondary concern is that we lose out on upstream efforts.</p> I think there is a path forward if we take this approach.</p> In addition to adding all the extensions that make for a predictable first-class glTF experience, we slowly handle the core glTF features as well using the same code paths.</p> We have the khr_materials_anisotropy</code> extension, but we could then add core_node_hierarchy</code> that would handle a core glTF 2.0 feature.</p> We could do this slowly over time, one piece at a time, replacing one core feature at a time until we have core_*</code>, where all glTF 2.0 core functionality is handled and wrapped around nothing.</p> This would let us slowly migrate away without replacing the world.</p> Conclusion / Key Points</h1> If glTF is our preferred asset format, we should make using it a first-class experience.</li> The root cause of the existing glTF problems is gltf-rs</code> not being well maintained.</li> We can fix this root cause by reviving the core project, forking it, or bringing it in-house.</li> No matter which way we go, we SHOULD & MUST not build an empire on a rotting corpse.</li> </ol> Kungsfors Protector Sleeve Unknown — Thu, 19 Feb 2026 00:00:00 +0000 This protective sleeve was designed to fit over the IKEA Kungsfors magnetic knife holder. The sleeve prevents knife edges from making direct contact with the metal surface, reducing the risk of chipping when placing or removing knives. The design slides over the holder and stays in place during normal use.</p> Learning Engrammer Caitlin Sar Campbell — Mon, 05 May 2025 00:00:00 +0000 New Keyboard New Layout</h1> I recently decided to buy a new keyboard after my the pleather shedding issue with trusty Microsoft ergonomic keyboard became too severe to ignore. As well as that keyboard has served me, when it started polluting my home something needed to be done.</p> After some research I landed on Keycron’s Q10 Max. The build quality is excellent, and the Alice style layout lets me stay in an ergonomic, but not too radical (i.e. split) form factor.</p> </p> The Q10 Max being wireless let me continue on my path towards a clean, clutter free, and wire free desktop.</p> I decided that, while I was at it I should consider alternative keyboard layouts. After all a new keyboard requires relearning muscle memory, why not double down?</p> I considered a few layouts, namely Graphite</a>, Engram</a>, Gallium</a>, and Hands Down</a>.</p> An important thing I learned in my research is that there seems to be a definitive break between post and pre covid layouts, with post covid layouts being substantially more well designed.</p> I ended up going with Engram variant because I liked the emphasis on roll-ins, and the inner column punctuation.</p> </p> I went with the Engrammer</a> because the brace and bracket locations in Engram where not great for software development. Engrammer has the same letter layout as engram, except with a more programmer centric symbol layout.</p> What I Did And How I Learned</h1> Learning Engram was extremely painful. I committed to a cold turkey approach and switched both my laptop and desktop layout to use Engrammer on day one.</p> </p> I also did 30 minutes of daily keyboarding practice on keybr.com</a> (which has many alternative layouts build in, including engram build in) daily for one month.</p> The learing process went something like this:</p> Week 1</h2> Pure Agony. If I worked a traditional job I surely would have been fired. My productivity dropped to like 5% on normal.</p> I couldn’t even play video games normally. I had to remap every game I played to use the new layout. (I know I could have switched back for games, but I wanted to commit 100%.)</p> Week 2</h2> Very painful. Posable to code but barely.</p> Wondered why I decided to do such a dumb thing.</p> Week 3</h2> Slow, but I can work.</p> At this point it felt like things where starting to come together.</p> Week 4</h2> Feeling slow but better.</p> Over the hump for sure.</p> </p> The main thing that helped was consistency. I practiced every day even if it was the only thing I did that day. My life basically revolves around typing in one form or another so even on bad days I had some motivation.</p> If I had one tip for people who want to learn a new key layout it would be to practice every day.</p> Impact</h1> It's been just over a month and I continue to practice daily. Thing get better daily. This blog post probably only took 20% longer to type than it would have if I used QWERTY/Z.</p> Funny thing is that I now struggle with QWERTY/Z.</p> Overall typing feels better now and I am happy.</p> Would I recommend learning a new layout? Yes, but only if you can commit hard. Otherwise the productivity drop would be too drastic for too long.</p> Box Fan Privacy Screen Caitin Sar Campbell — Sat, 05 Apr 2025 00:00:00 +0000 This privacy screen was designed to provide privacy by replacing the front grate of a box fan. It allows air to flow threw without allowing look in. Perfect if you want cool air and privacy! The grate was designed for a Lasko box fan but should work with other box fans.</p> 280mm x 150mm Crate Caitin Sar Campbell — Fri, 04 Apr 2025 00:00:00 +0000 This 280mm x 150mm robust crate was designed to hold root vegetables, but could be used for any heavy goods. This is being released as one of many simpler designs I made over the years.</p> Nasal Strip Holder Caitin Sar Campbell — Thu, 03 Apr 2025 00:00:00 +0000 This simple nasal strip holder was designed to be placed on a nightstand and keep things organized. The design is simple and trivial to change. This is being released as one of many simpler designs I made over the years.</p> Roller Blind Window Clip Caitin Sar Campbell — Sat, 28 May 2022 00:00:00 +0000 This roller blind window clip was designed to be compatible with Gardinia. This clip was designed after the original one was broken and a replacement was needed. This design is definitively stronger than the original design.</p> PanelDue 7i Case for the Railcore II Caitin Sar Campbell — Tue, 24 Mar 2020 00:00:00 +0000 This is my simple PanelDue 7i case for the Railcore II.</p> Secret Hitler Name Plaques Caitin Sar Campbell — Sun, 17 Nov 2019 00:00:00 +0000 A quick multi material 3d print project I put together for a friend. These are used in the VERY fun (and freely available) Secret Hitler</a> Game. If you like the game I would encourage you to support the creators by purchasing a pre printed card set from them.</p> Tall Laptop Stand Caitlin Sar Campbell — Fri, 06 Sep 2019 00:00:00 +0000 This project was my first ever venture into 3D design. I had just acquired a 3D printer and wanted to print something out for myself. This was created in "Parts" mode in FreeCAD. In the end the design worked out well and I used it for many years.</p>