[x3d-public] conversion of glTF metadata to X3D metadata
Michalis Kamburelis
michalis.kambi at gmail.com
Mon Oct 9 10:19:29 PDT 2023
In CGE/view3dscene we convert glTF "extras" to X3D Metadata.
Our practical use-case for it is that Blender allows to define "custom
properties" on various objects (Blender meshes, objects, cameras...)
and the Blender->glTF exporter puts these "Blender custom properties"
in "glTF extras". Being able to read these things in Castle Game
Engine allows authors to define some things in Blender that can be
game-specific and that are attached to particular objects, e.g.
- "this is a monster spawn point",
- "this is a destructible wall with 123 hit points",
- "this is lava",
- "walking on this floor hurts the player, taking 4 hit points per second",
- "this is a water volume, if player is inside this then it should be
treated as underwater".
So we convert glTF extras to X3D Metadata, and give CGE users easy way
to access this metadata, and everyone is happy, no matter what tool
and format they use -- they get possibilities :) See
https://castle-engine.io/blender#_custom_properties .
To turn glTF (most typical) key-map into X3D Metadata, we wrap it into
X3D MetadataSet called "ContainerForAllMetadataValues" .
glTF extras like this:
"""
"meshes" : [
{
"extras" : {
"mesh_custom_property" : 1,
"mesh_property_2" : "some string"
},
"name" : "Cube",
"""
-> are converted into X3D metadata like this:
"""
metadata MetadataSet {
name "ContainerForAllMetadataValues"
value [
MetadataDouble {
name "mesh_custom_property"
value 1
}
MetadataString {
name "mesh_property_2"
value "some string"
}
]
}
children Shape {
"""
See
https://github.com/castle-engine/demo-models/tree/master/blender/custom_properties
https://github.com/castle-engine/demo-models/tree/master/blender/custom_properties_2
for more examples, including both glTF, resulting X3D, and also source
Blender files.
Regards,
Michalis
pon., 9 paź 2023 o 16:49 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> Hi Holger,
>
> Thank you for your feedback. I did not think too much about the name
> for the Metadata node which holds the scene.extras json value.
>
> To me "scene.extras" is more of a programming convention whereas the
> value of a name string should be more abstract, or descriptive in a
> linguistic sense. So a dot would mean a full stop which would not make
> a lot of sense. But I can see that this is a rather aesthetic
> consideration, and that a direct json path style name has its own
> benefits by following very closely the glTF source..
>
> Let us know what you think,
>
> Cheers, Andreas
>
> On Mon, Oct 9, 2023 at 7:25 AM Holger Seelig <holger.seelig at yahoo.de> wrote:
> >
> > In X_ITE I also create a WorldInfo, but parse only the toplevel metadata so far.
> >
> > I like the way you described it, but why do you translate 'scene.extras' to 'scene_extras'? I would leave it as it is.
> >
> > Holger
> >
> > --
> > Holger Seelig
> > Leipzig, Germany
> >
> > holger.seelig at yahoo.de
> > https://create3000.github.io/x_ite/
> >
> > Am 09.10.2023 um 00:14 schrieb Andreas Plesch <andreasplesch at gmail.com>:
> >
> > glTF can contain rich metadata, on the toplevel and very targeted at
> > any sublevel.
> >
> > At any level, there is an "extras" property which can contain any
> > value including objects with arbitrary key:value pairs.
> >
> > At the toplevel, there is an asset object which has a set of defined
> > keys such as "copyright" (as well as its own "extras" property).
> >
> > In addition to this unstructured metadata for core glTF, there is a
> > metadata extension for more structured metadata, extensible through
> > namespaces:
> >
> > https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_xmp_json_ld/README.md
> >
> > There are many ways to map glTF metadata to X3D metadata. How should
> > we manage this ? It may make sense to coordinate systematic behaviour.
> >
> > x3dom uses the WorldInfo node for toplevel metadata:
> > - asset object properties go into the info field as key:value string pairs.
> > - asset.extras go into a WorldInfo MetadataSet "asset_extras"
> > - scene.extras go into a WorldInfo MetadataSet "scene_extras"
> >
> > In addition, "extras" at lower levels go into MetadataSets of
> > corresponding nodes, using the json value types for Metadata types.
> >
> > How do other browsers translate "extras" ?
> >
> > x3dom should also support the KHR_xmp_json_ld extension, by staying
> > very close and literal to the glTF data.
> >
> > One feature of the extension is that sets (packets) of metadata are
> > defined once at the toplevel, and then referenced (instantiated) from
> > any other level. This seems to map well into DEF/USE. A large
> > "KHR_XMP_GLTF" root MetadataSet would contain all metadata and just
> > referenced by USE from Shapes/Material etc. I think this could work
> > well. I think json property names can become Metadata name values, and
> > json value types can be mapped into Metadata types.
> >
> > If there have been thoughts or attempts to implement the glTF metadata
> > extension, any ideas or feedback would be great. Would it be useful to
> > start to think about a xml Metadata schema which follows the glTF
> > extension requirements and recommendations ? This may not be feasible
> > due to the extensible nature of the extension..
> >
> > Cheers, Andreas
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list