Scene format

[kayhhh]

We need some format for storing scenes / worlds. I see two options:

glXF

• A very unsupported format, would likely need to write our own reader / writer for it
• Works great with glTF

glTF Export

Is there a way to export a bevy scene as glTF? I don't see one, which would mean we also have to write this, which is not trivial.

BSN

• Bevy's native scene format, easy to use
• Not generalized, is specific to our implementation of the engine

I think glXF is ideal option. Would be better for long term compatibility, and would mean we lean in to the glTF format, doing everything within defined extensions which I like the idea of. However, we would have to write our own glXF import, exporter, and a glTF exporter... which is a lot.

[kayhhh]

gonna look into glTF exporting / glXF. If its too much we can just use BSN, then maybe migrate to glXF at a later point.

[Misterblue]

Also depends on what you want the functionality to be. GLTF can define scenes with all their contents. glXF seems to be focused on storing little "packages" if glTF items. This might be good for capturing assemblies (all the items and layout of a cafe scene that can be reused. Cesium's 3DTile format captures scenes and sub-scenes but organized in a scene-centric LOD structure (good for zoomable city-wide or country-wide viewing). Pixar's USD (Universal Scene Description) is geared to a layered, multi-author scene description. Anyway, it depends on what you want functionality you are looking for. If you are looking to have composable sub-scenes, glXF seems to be thinking in that direction. Then the workflow is lots of restaurant items built as GLTF objects, a glXF file that sets all the items into a cafe scene, and then a glXF file that sets the cafe inside a building (with its items), and then a glXF file that lays out the town (referencing all the glXF files that define all the "building" scenes). The downside, as you mention, is that glXF is not defined and it will be all the extensions that one would need to properly do such composite scene construction (like all the stuff in the Cesium 3Dtile definition).

[kayhhh]

Thanks for the input. I think you're right, best to think of glXF as a top level arrangement of items. This also helps keeps individual models as separate glTF files which is good for performance reasons, and aligns with the type of scene architecture I think I'm looking for - a simple base world made up of many independent assets.

It sounds like from what you're saying that glXF could also compose with itself by adding other glXF files to its scene which I hadn't thought about, but I really like this idea. Makes me think about where the scripting API I've been wanting should live, at the glXF or glTF level. My initial thought is glXF, as it lets us keep the scope of glTF smaller as it was made to be a delivery format like JPEG, but it might not give scripts enough control to just move whole models around instead individual mesh primitives or nodes within it. Maybe we could get the best of both worlds and let the scripts live as an extension on glXF, but have an API for stepping into a child glTF and modify values.

Also you mentioned LOD which I haven't given much thought. I think there's an MSFT_LOD glTF extension, so I guess it would be handled at the individual asset, aka glTF, layer. I don't think im too concerned at least for now with advanced tiling LOD like cesium has, but there could be some good stuff to pull from it for creating large (perhaps infinitely large?) scenes.