My application for glTF (digital anatomic atlases) requires binding application-specific metadata to glTF elements. I would like to do that in a robust way. As I’ve been thinking about the problem, it seems that a generic approach to handling metadata would benefit different kinds of applications.
It could in many cases negate the need for application-specific metadata extensions such as AGI_stk_metadata.
Goals
Top-level goals of such an extension include:
- binding metadata to arbitrary glTF elements, the gtlTF file itself, and the metadata itself (for authoring and versioning purposes)
- ability for metadata to survive most best-practices round-trip editing of glTF
- ability for multiple applications to store metadata without stomping on each other. For instance, I might have an anatomy model with all sorts of labels on nodes and scenes, but I might edit it in Blender, which might add rendering-specific metadata to the same elements.
- able to assign IDs to elements that can be addressed externally.
- able to support bind standard JSON types to glTF elements.
- support for “ref” values, which are URLs and treated as such.
- contain optional reference back to a schema that describes the metadata
Non-Goal
Out of scope is metadata below the glTF element level (e.g., no per vertex or per triangle metadata).
I’ve got a strawman draft design I can share that starts to address these goals, but I had a basic question or two first
First, has any attempt been made to create such an general purpose extension?
Binding questions
Then, what’s the best way to bind metadata to elements? Seems like there are three ways to do it.
First, containment: put the metadata in the element itself. This might be hard for applications to deal with both rendering and metadata.
Second, you can bind by reference (metadata has a reference to the element). And there are two ways to do that: by index or using the “name” field.
The “name” field seems a underspecified in glTF; perhaps a human-readable name, or maybe an ID. AGI_stk_metadata treats it like an ID. Nothing else in glTF uses “name” as a way to reference nodes, doing so in a standard would require building a global index, and there could be name clashes.
By index could look something like this:
"EXT_metadata" : {
...
"meshes": {
"0": { ... metadata for mesh 0 ... },
...
},
"nodes": {
"100": { ... metadata for node 100 ... },
}
... and so on ...
}
This scheme is unambiguous and can address any glTF top-level element. It is potentially brittle if elements move around during editing (although the scheme above would allow a naive application to renumber the metadata without knowing about its contents).
Once some of these core questions are answered, most of the rest is naming and engineering, I think.
Thanks for any insights the community may have!
