[x3d-public] Mantis [X3D 0001272]: glTF import needs to include metadata import

Michalis Kamburelis michalis.kambi at gmail.com
Wed Apr 28 03:38:04 PDT 2021


I'm going to post here a comment that Don can hopefully paste in Mantis.

Although I'm logged-in as a member, Mantis remains read-only for me.
Trying to post a comment from
https://www.web3d.org/member-only/mantis/view.php?id=1272 sends me to
https://www.web3d.org/member-only/mantis/bugnote_add.php with "Page
Not Found" information. I tried logging out + in on both Mantis and
web3d.org, to no help.

The answer to that glTF metadata issue:

--------------
>From my point of view, this is "done". Namely, we have a way to
express existing glTF metadata (mentioned in the description of this
ticket) as X3D metadata. So import is possible.

Castle Game Engine / view3dscene are doing that already: glTF "extras"
are converted into X3D MetadataXxx nodes at import. As a demo, you can
look into

- 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

This shows Blender "custom properties" which are exported as glTF
"extras" which are in turn converted into X3D MetadataXxx nodes when
importing this glTF in CGE/view3dscene.

The glTF "extras" are most important here, as they are a "free"
key-value pairs that can be associated with various glTF objects, and
so they are the closest equivalent of X3D MetadataXxx nodes.

To break down the details from
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#asset-1
:

* copyright from glTF -> Done: the standard way to express it in X3D
is META / <meta> information at the top-level of the X3D file.

* generator from glTF -> Done: as above, the standard way to express
it in X3D is META / <meta> information at the top-level of the X3D
file

* version from glTF -> Done: this could be converted to X3D META /
<meta> , or ignored. Once glTF is imported, this information is not
really relevant for person looking at resulting X3D nodes graph.

* minVersion from glTF -> Done: as above, this could be converted to
X3D META / <meta> , or ignored. Once glTF is imported, this
information is not really relevant for person looking at resulting X3D
nodes graph.

* extensions from glTF -> Done: as above, this could be converted to
X3D META / <meta> , or ignored. Once glTF is imported, this
information is not really relevant for person looking at resulting X3D
nodes graph.

* extras from glTF -> Done: convert to X3D MetadataXxx nodes.

To address @vmarchetti comment:

I agree, that is: importing glTF (e.g. using """Inline { url
"blabla.gltf" }""") shall NOT modify any "exterior Metadata nodes". As
you describe, this would be problematic, when many files (with various
formats -- X3D, glTF) are inlined, it would be confusing "where does
metadata go". Fortunately, we have in X3D MetadataXxx nodes "tied" to
any node at any level. So

- When importing a glTF model with glTF "extras" attached to some glTF
mesh, then we can generate X3D MetadataXxx nodes "tied" to the created
X3D Shape/geometry.

- The top-level X3D META / <meta> are already present at every model,
so every Inline (whether it inlines glTF, X3D or anything else) is a
new place to store per-model META / <meta> information already.

So, X3D metadata (generated from glTF content) can (and should) stay
inside the X3D nodes graph generated *from this glTF content*, and
shall not "pollute" any X3D nodes outside.
--------------

Regards,
Michalis



More information about the x3d-public mailing list