[x3d-public] conversion of glTF metadata to X3D metadata
Andreas Plesch
andreasplesch at gmail.com
Mon Oct 9 10:49:19 PDT 2023
Thanks, Michalis. x3dom does pretty much the same mapping of extras to
metadata, with minor differences:
The name of the MetadataSet is "extras" except for "scene_extras" and
"asset_extras" for WorldInfo MetadataSets.
Numbers become MetadataFloat rather than MetadataDouble.
MetadataDouble is more appropriate for the json number type, I
believe, but MetadataFloat seems more commonly used in X3D since 32bit
suffices in most cases.
Here is the full conversion:
https://github.com/x3dom/x3dom/blob/master/src/util/glTF/glTF2Loader.js#L149
Does CGE convert the asset object as well ?
I am also looking for examples of uses of the glTF metadata xmp
extension but could not find much so far. I suspect Adobe may have
such examples.
Best, Andreas
On Mon, Oct 9, 2023 at 1:20 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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 tro 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
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list