[Question] Extension/Plugin Architecture

[camnewnham]

I'd like to add a feature which reads meta/extension data from a node and performs an action based on this, formatted similarly to KHR_lights_punctual. As the extension is application-specific it's not suited to a PR in this repository. Is there a way to plug-in or extend the parser without forking the project?

Cheers

[atteneder]

That's a great suggestion and something I've been thinking about already.

The biggest obstacle is probably the JSON parsing by JsonUtility. Adding custom properties currently requires changes to the schema classes or a second parsing pass (which is slow). I'd love to implement a better JSON parser, that allows better customization first.

[camnewnham]

Yes I thought so. Is file size the main reason for using JsonUtility in the first place?

For example with Newtonsoft it might be possible to create generic JObjects for extension information that plugins can then parse via an event or callback.

[atteneder]

Yes I thought so. Is file size the main reason for using JsonUtility in the first place?

Yes. I noticed WebGL builds are ~1 MB (wasm) smaller when not referencing Newtonsoft JSON.

JsonUtility is also quite fast as well. Unfortunately it lacks some features required for glTF, so there are some workarounds in glTFast.

For example with Newtonsoft it might be possible to create generic JObjects for extension information that plugins can then parse via an event or callback.

I'll definitely look into Newtonsoft again. Even if it'll be ruled out for build size reasons, its API might be worth exploring.

[mikeskydev]

Hi, has there been any more thought given to how you'd like to see an extension API implemented? A few of us over at the OMI group would like to use glTFast as the basis for implementing our proposed glTF extensions in Unity. Happy to explore this with you to find the best solution for everybody!

[atteneder]

Hi, has there been any more thought given to how you'd like to see an extension API implemented? A few of us over at the OMI group would like to use glTFast as the basis for implementing our proposed glTF extensions in Unity. Happy to explore this with you to find the best solution for everybody!

Allowing users to inject their own extensions into glTFast in a good way (flexible yet performant) is something I definitely want to make happen! I want to be frank when I say up until now there have been more urgent matters (and there still are some), so no, I haven't given it any detailed thought yet. What I already know is that the current JSON parsing module needs replacement to enable more flexible parsing.

I'd be open to start the conversation with one or multiple exemplary extensions candidates to sketch a first draft API and get feedback from you.

@mikeskydev Could you think of a good fit for such an extension?

[mikeskydev]

What I already know is that the current JSON parsing module needs replacement to enable more flexible parsing.

Yes, due to the limitations of JsonUtility? The UniVRM project has a custom UniJson parser which is used for arbitrary extensions, which may be worth looking at as a basis. Performance is definitely a consideration here.

Could you think of a good fit for such an extension?

We've been working on OMI_audio_emitter which adds audio files to glTF, so in Unity that would be represented by an Audio component. As this is one of the standard Unity components to have on a GameObject I think it would be a good fit for testing. We already have sample assets and a three.js implementation to work from.

We've set up a fork in the OMI organisation to begin exploring the best way to approach this.

[atteneder]

@mikeskydev Sounds great! Keep me posted.

[mikeskydev]

Just to update from my side, I've been testing the various parsing speeds of different JSON libraries. This has been tested against a large .glb file we have internally at my company:

The fastest one so far that's close to unity's JsonUtility is SimpleJSON: https://github.com/Bunny83/SimpleJSON/blob/master/SimpleJSON.cs

The API here is fairly simple:

var data = JSON.Parse("{\"hello\":\"there\",\"responses\":[\"general\",\"kenobi\"]}");

Debug.Log(data["hello"]);
Debug.Log(data["responses"][0]);
if(!data.HasKey("not_here"))
    Debug.Log("Could not find node not_here");

At least at first glance, it seems like it could swap out in place of the FakeSchema fairly well for arbitrary lookups.

[atteneder]

@mikeskydev Thanks for that initial research!
I hope I can dig into this topic (early) next year. Extension API will become very important seeing how devs are pushing for metaversy glTF extensions!

[mikeskydev]

I see there's a branch that adds newtonsoft, is it safe to assume that's the parser selected for arbitrary extensions/extras going forward?

[atteneder]

I see there's a branch that adds newtonsoft, is it safe to assume that's the parser selected for arbitrary extensions/extras going forward?

Yes, but:

• It's just a proof-of-concept that showed advanced parsing can be added quite easily
• Newtonsoft JSON has downsides (build size, speed), so even if it lands it will be optional and does not exclude a potential third solution in the future.

[mikeskydev]

I searched glTFast on Unity forums and couldn't help but notice Unity appears to have an internal fork at v6, with extension support a bit more fleshed out!
https://docs.unity3d.com/Packages/[email protected]/changelog/CHANGELOG.html

Is there a lot of work happening internally at Unity now? When are we likely to see this in the main repo?

[atteneder]

Sorry for the late reply.

Indeed a lot has happened and is in the making.

As you noticed correctly, in version 6.0.0 we shipped support for Add-ons, parsing via Newtonsoft JSON and access to meta-data (e.g. node.TryGetValue<int>("myCustomProperty") or node.extras.TryGetValue<string>("myCustomProperty")).

With that I'm going ahead and close this issue. Feel free to re-open or open new issues ideally with targeted/narrower scope.

The next important follow-up milestone in that context is #735 .