atteneder
Write node `extras` during export
During import, it's possible to process extra data from the nodes. It would be great if it would also be possible to write extra data during export.
I've searched but I've only seen it mentioned on #260 which dates back to 2021. Would you be willing to accept a PR for this?
@atteneder I've got a working version, however I'm not sure why the node's Extras prop is of type Dictionary<string, object> when the values are always cast to IJsonWritable? Wouldn't Dictionary<string, IJsonWritable> make more sense?
Hi,
From the top of my head I can't follow you :)
Could you point me to mentioned Extras property? A permalink to the file on GitHub would be great!
Thanks!
Hi!
I only realized afterwards that the API I was talking about came from @OwenSignaturize's branch here. So, you can ignore my second comment.
On another note, I spent quite some time figuring out what the relation between this repo and Unity's fork is - it's very confusing, since the fork says it's 62 commits ahead (and none behind), yet this repo was more recently updated. It also looks like it's you maintaining both repos, so inevitably the question is why? But more importantly, which repo should we fork for upstream changes? Also, why does the fork need a CLA for an Apache-licensed project? This is so weird.
Anyway, clearing this up somewhere in the README would be very helpful.
Hi @freezy ,
I cannot support other's branches, but I'd gladly look into a PR, should @OwenSignaturize draft one.
Heads-up: Exporting custom (extras) properties is not planned on our side in the upcoming months, but definitely of value (while not too hard to implement, I presume).
With regards to the dual repository situation....it's complicated.
TL;DR: Technical and legal requirements imposed by Unity and the way GitHub works (bills).
There's actually a third (internal) repository where the internal work happens. The previous modular setup (separate tests, sample projects, etc.) used Git submodules, which was incredibly complicated with the 2x mirror setup Unity required. Hence we transitioned to a monorepo structure. But that one now contains many large Git LFS test assets (and is planned to grow considerably), which is something GitHub would bills me on the original repo. I decided to just sync the actual package upon release, which explains the incompatible Git histories. Long-term I want to sunset the original repo and hand them over to Unity. Maybe even the OpenUPM release. The CLA is a Unity requirement. I presume for protective reasons.
Now you know.
hth
Hi @atteneder, thanks for your summary, that clears it up for me. For my project, I've pivoted to keep metadata apart from the GLB in my file export since there are other files to export anyway. Thus, it's moved down in my priority list. And since I don't want to sign a CLA, the issue is somewhat off the table for me.
The project itself, however, is very valuable, so many thanks for that! ❤