Custom Properties - Deserialize extras property in node.extras

[chrisssssy]

Hello @atteneder ,

it would be great to get notified whenever an gltf-file is loaded, which has an extras property in one of its node objects. Maybe fire an event when that happens and pass a reference to the corresponding unity gameobject/node and the extras data as json-string. Another way could be to create a monobehaviour and attach it to the gameobject and pass the json-string in there. After import i could find all gameobjects with the extras-property with GetComponents<>().

My usecase is to add a different monobehaviours to some of the gameobjects depending on the extras-properties. I attached a zip file with an gltf file from blender, where i added 2 custom properties which i'd like to access.

BlenderCube.zip

[atteneder]

Hi @chrisssssy ,

Reasonable feature request! The glTF spec says, it recommends extras to be an object with key-value pairs of strings, which in your case, it is. I use Unity's JsonUtility for parsing, so it wouldn't be very flexible (for other structures) anyways.

Not sure where to place it in the planning timeline though. I see other features (like stable KTX support or animation) more important.

[chrisssssy]

Hi @atteneder

thank you for your quick reply. I managed to implement it for nodes.extras myself. But of course the extras property could be used in every other property as well, like mesh.extras or in the root itself. Also, like you mentioned, in order to deserialize it with JsonUtility, i had to encode my metadata in another json-string and put it in an string variable in the extras property. Later i can take the json and deserialize it to my own classes depending on the type. I'm sure there is a smarter solution, but for know this ist working for my use-case. If you are interested, i can share the code with you.

[atteneder]

Sure, create a PR! Maybe I accept it right away. Worst case I use it as a starting point for a better solution.

[kt-Andreas]

Hello @atteneder

I would like to know if there's already a plan on when and how you are going to work on this feature, because I'm highly interested in implementing this in my project.

@chrisssssy Would you mind if you shared your provisional implementation with me? 😄

[chrisssssy]

Hi @kt-Andreas

i could not figure out how to make a pull request, so i will upload the changes here. And for your information, i did these changes with a much older version of gltfast. I think it was version 2.0 or something, so the files changed quite a bit since then, so i am not shure if it will still work, but here is what i did (all changes are commented with // chrisssssy). 1) added an entry in Node.cs for the custom data. Right now it just contains one string property called "data". 2) added an event in GltFast.cs which gets called if there was an extras property on that node. The check for this property is somewhere in the "CreateGameObjects" Method which loops through all nodes. 3) added a method in "GetGameobject" in GameObjetcInstantiatior.cs . This returns the Unity GameObject which had the custom properties.

Now you can just create a unity script an listen to the GLTFast.ExtrasFound Event.

changed files.zip

edit: i added the pull request below

[mespino-cityzenith]

Hello,

First, thank you for developing this library. I expect this package to be officially supported by Unity soon.

We are considering to use GLTF in our application. We are using CAD files and our idea is to use gltf as a visualization format. The problem here is that we need to maintain the metadata structure. I've seen that @chrisssssy has done already some progress in that direction and that this feature is already on the roadmap, but I'd like to know if it is scheduled in the short time or either in a middle-long time.

Thanks

[atteneder]

I've seen that @chrisssssy has done already some progress in that direction and that this feature is already on the roadmap, but I'd like to know if it is scheduled in the short time or either in a middle-long time.

Thanks for reaching out @mespino-cityzenith !

So far I haven't gotten much requests for meta-data, thus it's not planned near-term.

I've reviewd @chrisssssy 's work now and I think it needs adjustment.

What does your metadata structure look like? Is it a simple string in node.extras.data or a richer, custom JSON structure? Are you using the XMP extension?

[mespino-cityzenith]

The metadata is just a key/value list. It doesn't have any homogeneous schema because it could have any key-value pair

What I'd do is to create a component with a key/value list and add this component to the child corresponding to the node, filled with the key-value list parsed from the gltf node Something like:

public class Extras: MonoBehaviour
{
public string [] keys;
public string [] values;
}

Anyway, if it is not in your roadmap, don't worry.

Thank you for your help 👍

[atteneder]

@mespino-cityzenith

Thanks for sharing this insight. glTFast currently uses JsonUtility for JSON parsing, which makes it, well, fast. Unfortunately it's not very flexible, especially when it comes to parsing JSON structures unknown at build time (like yours).

I totally want to enable uses cases like yours, but this needs a bit more research and refactoring first.

This is related to #226

[atteneder]

Minor update:

I've made a proof-of-concept that parses meta data in the extras property and makes it accessible to a custom instantiation implementation. It's in this branch:

https://github.com/atteneder/glTFast/tree/demo-metadata

The key is that it used Newtonsoft JSON for parsing instead.

[Dodgerer]

Hi! Just started to use gltFast plugin for Unity with the help of your example scripts . Importing .glb at runtime. How to import metadata with the file? c# novice.

Thank you! /Olof

[Dodgerer]

Ok I figured it out! Found the greyed out code in your examples! 👍🏼

Thank you for this! Will this be implemented in official release any chance?

[atteneder]

I'm investigating all options at the moment and gather early feedback to make sure the best solution wins.

[VikasB1904]

Hi @atteneder I am need to get the extras dat stored into the each node of the gltf file. My Data structure stored in the extras is complex one, it contains the key-value, as well as some arrays and some objects too. I was trying you package given here https://github.com/atteneder/glTFast/tree/demo-metadata But I can see there no package for this branch. I have downloaded this branch code on my machine but I don't have any idea how to build that. Can you guide me to build this branch project so that I can create the package out of it and use it in the unity project? (If you have any other better approach to use this meta data branch in my unity project you can suggest that too)

Thanks

[Dodgerer]

@atteneder It seems that the metadata branch based on the version glTFast 4.8.5 doesn't work or I am doing something wrong? when loading the old one based on 4.8.3 it works again. Any ideas? 4.8.5 is much better for me in regards of materials. When loading the metadata package in unity it says version 5.0.0-exp.1?

[atteneder]

Keep in mind, it's WIP.

But what does "does not work" mean? Also, how is 4.x better in regards of materials?

Yes, the main branch is version 5.0.0-exp.1 at the moment.

[VikasB1904]

Hi @atteneder,

Can you help me to build the project I have downloaded form the https://github.com/atteneder/glTFast/tree/demo-metadata branch. I have no clue how to include this in mu existing unity project.

Thanks

[msimtmv]

Hello, the branch 404s for me. I would like to use extras (https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-extras), and I thought this was supported but then I saw only the concept of MeshExtras is in the project.

In our case, we need to assign specific unique ids to the nodes, so we are saving it as extras in the nodes

[AbrarZShahriar]

Any updates on the metadata stuff?

[atteneder]

In version 6.0.0 we've added support for parsing the glTF's JSON part with Newtonsoft JSON as alternative. This allows users to access known extras properties (see example).

In the last weeks I've experimented with more sophisticated meta-data import/export and came to the conclusion that a breaking-change refactor is likely required to pull it off. Hence a more improved access to meta data will be delayed.