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

Support BSON with .glb format #2321

Open
OhmygodWorks opened this issue Sep 8, 2023 · 2 comments
Open

Support BSON with .glb format #2321

OhmygodWorks opened this issue Sep 8, 2023 · 2 comments

Comments

@OhmygodWorks
Copy link

Will BSON (binary JSON) suitable for .glb format as they are both binary format?

@javagl
Copy link
Contributor

javagl commented Sep 8, 2023

The is no support for BSON right now.

Theoretically, there could be a dedicated chunk type for this. So in addition to JSON or BIN, there could be BSON. But AFAICT there currently is no mechanism in place for defining new or additional chunk types.

Brainstorming: One could, even more theoretically, try to construct an extension, that still stores a (small) JSON, and just delegates to the BSON data, very roughly like

{ 
    "asset": { ... }
    "extensions": {
        "EXAMPLE_bson": {
            // Refers to the chunk in the binary buffer that contains
            // the actual JSON structure, but as BSON
            "chunkIndex": 2
        }
    }
}

But I don't have an idea how feasible this is in practice, or how widely it would be implemented.

@donmccurdy
Copy link
Contributor

Personally, I think if an application developer wants to use BSON, they should think of that as a 'wrapping' format, rather than as a variant or extension to glTF, and just encode the data as they wish. Similar to how the 3D Tiles standard embeds glTF today, without requiring incompatible glTF encodings.

Introducing BSON (or other alternative encodings like MessagePack, CBOR, or protobuf) within the glTF standard would be a substantial breaking change that requires a v2 → v3 bump in my opinion — not because an extension couldn't technically work, but because it's just that big of an ecosystem shift. I'm not currently in favor of such a change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants