Proposal: Unity JsonUtilitity Serialization Option.

[StephenHodgson]

I'd like to start the discussion about making the Json Serialization options open to developer needs.

Right now the Newtonsoft dll is a hard dependency that every asset package seems to have conflicts with. I'd like to keep the existing functionality, but add a native Unity Json Serialization option for those that don't want to have Newtonsoft in their projects.

See #178, #60

[blgrossMS]

The Newtonsoft JSON dependency comes from the GLTFSerialization project. Replacing it with Unity JSON serialization is not the solution (or having an option, it just recouples together the serialization logic and the Unity code). The real work item that is needed is to not expose JSON types through the GLTFSerialization project

[StephenHodgson]

It would also help with the issues people are having with different newtonsoft dll versions

[StephenHodgson]

Here's a nice article comparing the serialization performance of a few libraries for reference.

https://jacksondunstan.com/articles/3294

(The data is a bit old, but I'd love to redo this test with more modern versions of each)

[blgrossMS]

There is also this one: https://jacksondunstan.com/articles/3303

However the perf analysis does not take into account the considerations outlined in this article: https://www.newtonsoft.com/json/help/html/Performance.htm

Which we use (manual serialization/deserialization instead of reflection). It would be interesting if we had both methods to do a perf analysis.

The abstraction layer between the serialization and deserialization and Unity is useful. Our project is architected in such a way that we want to be able to have strongly typed classes in a dll that is Unity agnostic. MRTK is somewhat similar in it's architecture (though they are not using UnityGLTF that way). I imagine others are as well.

My intention is to move the C# parsing library out of this repo and having UnityGLTF consume the dll's from it.

I am fine with the idea of allowing different JSON deserializers/serializers (like the Unity specific one). I think the ideal architecture that should be implemented is something along the lines of:

1. Keeping data model classes as they exist today (GLTF Data Model dll)
2. Providing an interface for specifying the serialization/deserialization of those classes (This could be the future GLTFSerialization dll)
3. Having Unity do a construction of elements based on those data model classes (UnityGLTF project)

In the past we have wanted to move towards an auto gen version of the C# library for serialization/deserialization to prevent manual work being done.

Is that basically what you are proposing?

[StephenHodgson]

MRTK is somewhat similar in it's architecture (though they are not using UnityGLTF that way)

I wish we were doing it more like that. Some of the major issues we get from users is that they get conflicts with the newtonsoft dll from other imported assets, which is why I want to move away from it. Although, if Unity does move towards natively supporting glTF, then that issue will go away. We're just trying to limit the dependencies we have to take on, and pass on to our consumers.

[StephenHodgson]

I am fine with the idea of allowing different JSON deserializers/serializers (like the Unity specific one). I think the ideal architecture that should be implemented is something along the lines of:

1. Keeping data model classes as they exist today (GLTF Data Model dll)
2. Providing an interface for specifying the serialization/deserialization of those classes (This could be the future GLTFSerialization dll)
3. Having Unity do a construction of elements based on those data model classes (UnityGLTF project)

This sounds fantastic. Which is kinda what I was doing. I had initially started with a few interfaces for serialization, and was going to keep much of the core data classes alone.

[StephenHodgson]

I finished up the change to use the JsonUtility, but I'm still working on a nice way to support both and giving devs the option of choosing which to use.

I did run into an issue with the Extensions and Extras being a dictionary, but I found a way to work around it.

[StephenHodgson]

I'm just gonna leave this here for people to try out.
Uses json utility serializer, and doesn't require the use of custom shaders. No support for extensions yet.

https://github.com/StephenHodgson/glTF-Unity

[chrisfromwork]

@blgrossMS is anyone actively working on this issue?