Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scene format #818

Open
kayhhh opened this issue Nov 2, 2023 · 3 comments
Open

Scene format #818

kayhhh opened this issue Nov 2, 2023 · 3 comments

Comments

@kayhhh
Copy link
Member

kayhhh commented Nov 2, 2023

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 kayhhh added this to UNAVI Oct 30, 2023
@kayhhh kayhhh converted this from a draft issue Nov 2, 2023
@kayhhh kayhhh moved this from 📦 Backlog to 📋 Next up in UNAVI Nov 2, 2023
@kayhhh kayhhh moved this from 📋 Next up to 🏗️ In Progress in UNAVI Nov 2, 2023
@kayhhh
Copy link
Member Author

kayhhh commented Nov 2, 2023

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
Copy link

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
Copy link
Member Author

kayhhh commented Nov 3, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏗️ In Progress
Development

No branches or pull requests

2 participants