Access to extra data in glb file about cgltf HOT 12 CLOSED

Maybe we can start with just the character range, and then if necessary we could provide helpers to parse that separately (cgltf_parse_extra that could take a callback, or return a list of key-value pairs, or something similar).

from cgltf.

Oh also "extras" can be in basically every single node, so we'll need to modify most structs to include this. Maybe as a first blush we could have cgltf_extras struct that has a list of key/value string pairs, as well as a full JSON dump for more complex usecases?

from cgltf.

@dradix , can you provide a sample glTF or glb file that contains typical extras data?

from cgltf.

This feature is very useful for game engines where any object can contain various extra data.

A random example:

{
    "cameras" : {
        "perspectiveCamera_id" : {
            "name" : "MainCamera",
            "perspective" : {
                "aspectRatio" : 1,
                "yfov" : 0.5,
                "zfar" : 1000,
                "znear" : 0.05
            },
            "type" : "perspective",
            "extras" : {
                "hash" : "C1BE5A6944942D071CCE265D2089C0A7",
                "uuid" : "82e3597e-76c9-11e9-8f9e-2a86e4085a59",
                "scripts" : "main_camera.c;player_camera.c"
            }
        },
    }
}

Specification reference.

from cgltf.

Thanks for the example! I agree that it’s very useful.

At the moment, I’m just as a first step looking for sample assets to come up with a design and subsequently be able to test.

from cgltf.

Here: Sample.zip

from cgltf.

I'm interested in this as well but not sure what the design should be. The complexity is that "extra" can be completely arbitrary JSON. We could make a generic JSON API (that seems heavy-handed), expose jsmn token range (that seems odd) or return a character range in the original JSON document and require user to parse (that doesn't seem useful). Great choices all around! 😜

My specific use case is I want to just preserve the extra information in the node without modifying it, but I'd imagine that it's more common to have to parse it out.

from cgltf.

Maybe we can just pass data to the application as is (string/bytes?), and let the user choose how to handle it (JSON/YAML/TOML/custom)?

from cgltf.

The approaches we have here are also pretty much what I’ve come up with. Additionally, we could also do callbacks for extra data so that the user can process it to what’s required.
But I don’t really like that either. My current favorite is handing out the character range I think as it has the smallest overhead and the greatest flexibility.

from cgltf.

The first part is in PR #62. Did I miss anything?

from cgltf.

I've lightly tested this and it works for me.

from cgltf.

That's good enough then for now. If anyone needs anything more let me know.

from cgltf.