Closed lilleyse closed 2 years ago
Would wait to see if this is useful in practice as it couples the tileset JSON and the tiles.
Also, I don't think we should add any new issues labeled 1.0
at this point.
This could be useful for the new WebP glTF extension, where Tilesets that use glTF's with this extension may fail to load on clients that don't implement a fallback.
I recently ran into this as well, being able to get a list of required extensions for b3dm/glTF payloads is pretty critical to writing a generic cross-browser tileset viewer.
Does 3D Tiles contain any other payload that have, or might in the future have extensions? Is it sufficient just to have gltfExtensionsUsed
and required? I guess it doesn't matter because if format X
in the future has extensions we can add XExtensionsUsed
at that point then?
More generally should a tileset list the glTF features in use (if that can even be defined)? Should all 3D Tiles clients be expected to support the full glTF feature set?
This topic came up on the forum: https://community.cesium.com/t/should-3d-tiles-spec-formalize-gltf-restrictions/9667/2
How would a viewer implement forward compatibility? It seems it would be up to the 3D Tiles / glTF author to suggest fallback options for viewers that can't handle certain (new) features. Like a shader author that implements fallbacks for older hardware. It would be nice if there was a mechanism for 3D Tiles authors to do this. Would that be a unique capability for 3D file formats?
This was included in the 3DTILES_content_gltf
extension, see this section
Should glTF extensions used by embedded glTFs be listed in the tileset JSON somewhere?
Examples: a tileset uses
KHR_draco_mesh_compression
orKHR_techniques_webgl
, which not all implementations may support.If we decide to add this it would probably be two top level tileset JSON properties called
gltfExtensionsUsed
andgltfExtensionsRequired
.