Open thepackett opened 8 months ago
Relevant: #11138
I like #11138 as a good short term solution, but my hope with this issue is to develop a more robust solution for GLTF extensions in bevy since it is a very important part of the GLTF ecosystem. It's a significant undertaking which may take a while though, so I think it would be a good idea to have #11138 merged first. Any extension support is better than no extension support.
GLTF High Level Overview
GLTF stands for Graphics Library Transmission Format, and is an industry standard file format for representing 3D scenes developed by the Khronos Group (known for OpenGL, Vulkan, etc). GLTF files can take two different forms:
.gltf
which is a JSON file describing a 3D scene along with resources (.bin, images, etc) either stored externaly in binary/image/etc files, or internally in base64 encoded strings..glb
which stores the gltf asset (JSON, .bin, images, etc) in a binary blob.In addition to the core GLTF specification (which covers most things like textures, meshes, scenes, etc), GLTF also supports
Extensions
.Extensions:
An
Extension
is additional data that can be appended to any JSON object in a gltf file to provide additional functionality. For example, theKHR_materials_ior
extension appends a single float to a material that represents its Index of Refraction.Extensions
were designed to be an interoperable way to extend GLTF functionality without affecting the core GLTF specification, with unsupportedextensions
simply being ignored. However, someextensions
do need to affect the core GLTF specification in a non-interoperable way. For example,EXT_meshopt_compression
which appends pointers to buffers containing compressed mesh data makes the original non-compressed mesh buffer pointer optional (it may be included for interoperability, but it somewhat defeats the purpose to include both compressed and uncompressed data).All
extensions
used must be listed in the root GLTF object'sextensionsUsed
array. If an extension produces a core GLTF specification non-compliant file, then the extension must be listed in the root GLTF object'sextensionsRequired
array.GLTF Specification:
The full GLTF specification can be found here.
GLTF in Bevy
How it currently works:
Bevy currently uses gltf-rs to parse a
.gltf
file's bytes into a rust friendly data structure which is then used to fill out our internal GLTF representation with data. Our internal GLTF representation covers the core GLTF specification, as well asExtras
. However, Bevy does not currently support any extensions, GLTF compliant or non-compliant, and because of this we are missing out on a large number of very useful GLTF features.Objective:
Bevy needs a flexible internal GLTF representation that can support GLTF compliant and GLTF non-compliant extensions, as well as a way for users to implement their own custom GLTF extensions.
After looking into every officially ratified GLTF extension, I found that only
KHR_draco_mesh_compression
,KHR_mesh_quantization
,KHR_texture_basisu
,KHR_texture_transform
,EXT_meshopt_compression
, andEXT_texture_webp
can create non-compliant gltf files. These extensions fall into two categories:KHR_draco_mesh_compression
,KHR_texture_basisu
,KHR_texture_transform
,EXT_meshopt_compression
, andEXT_texture_webp
all follow the pattern of making some part of the original gltf specification optional.KHR_mesh_quantization
is unique in that it allows mesh data to be represented by other data types than a float, which the original spec requires. It is also unique in that it is not possible to specify a fallback, and so if this extension is used it must be required.With this in mind, we can come up with some (potentially unreasonable) goals for Bevy's GLTF implementation:
AssetLoader
andAssetSaver
for any combination of GLTF extensions.This list is not set in stone and may change as I work on implementing extensions.