Project Architecture

[robertlong]

Notes from our meeting with @MSblgross, @stevenvergenz, and Ken Wolfe.

• Blake will be splitting his pull request into separate parts so that it is easier to review.
• glTF Serialization/Deserialization will be split out into a separate project within this repo and moved to a separate Khronos repo when ready.
• We'll be keeping the "UnityGLTF" name for the Unity project and using "GLTFSerialization" for the external serialization/deserialization project.
  • Note: Capitalization of GLTF will be kept this way for the sake of C#'s Pascal case for class names.
  • In the future we may try to generate the serialization code from the glTF JSON Schema, but there is additional work needed to add manual deserialization using JSON.NET.
• Once Blake's architecture changes have landed we'll be breaking the importer/exporter code into classes for importing/exporting specific sets of Unity components.
  • An example would be MeshImporter which would generate Unity Mesh objects, cache them, and add the correct components (MeshFilter and MeshRenderer) to a node.
  • The importer/exporter will hold fields for the component importer/exporters to be used and can be extended as necessary.
  • I'll be working on a PR for these changes and have more details to discuss with the community soon.
• Once the architecture changes are made the focus will be on supporting the full glTF 2.0 spec for runtime import.
  • @PlutoVR has been working on animation support, we'd really like to work with you to get that merged into the repository. Let us know what we can do to help.

If there are other changes you'd like to see to the architecture of the project please let us know. Ideally after making these large architectural changes we can get to a versioned, pre-alpha release and a more stable place for anyone trying to use UnityGLTF.

[blairmacintyre]

Does the plan include outputting animated elements (models) as glTF?

[robertlong]

That's the plan. We'll work towards full export support as we go. However, right now we're focusing on project architecture so we can break out some of this work and hopefully clean up integration points. Hopefully we can get that done relatively soon.

After that I believe @MSblgross and I will be focusing our efforts on getting full glTF 2.0 support for import. I plan on moving back to export after import is fully featured.

However, work can be done in parallel on supporting the remaining export features. If you or anyone else want to help out it would be greatly appreciated!

I know @bghgary and the folks at @sketchfab have worked on animation export from Unity in their projects. Gary's involved already and it would be great to see if Sketchfab wants to contribute.

https://github.com/bghgary/glTF-Tools-for-Unity
https://github.com/sketchfab/Unity-glTF-Exporter

[robertlong]

We're still trying to decide on the final namespaces for the project before we merge #50

I have a proposal here and I could use some feedback from the community.

Example of the proposed namespaces:

using UnityEngine;
using GLTF;
using UnityGLTF.Extensions;

namespace UnityGLTF { 
    class GLTFComponent {
        public GLTF.Scene Scene;
        public GLTF.Math.Vector3 GLTFVector;
        public GLTF.Serialization.GLTFParser GLTFParser;
    }
}

Another issue is splitting this repo into two. Ideally the GLTF folder would be split off into its own repository. It would be responsible for the same things that glTF-CSharp-Loader is doing, but with optimized hand written JSON serialization/deserialization rather than automatically generated from the spec's JSON schema and serialized/deserialized using reflection which is considerably slower (See #10).

It would also have a name like glTF.NET or glTF-CSharp which could get confusing.

So to recap, the decisions we need to make are the following:

1. GLTF Serialization/Deserialization project namespace (Ex. GLTF)
2. Unity Import/Export project namespace (Ex. UnityGLTF)
3. Should we split the repositories now or keep them in folders in this repo like they are in Initial architecture update #50
4. If we split the repositories, what should we name the Serialization/Deserialization project (Ex. glTF-CSharp)
5. What is the future plan for merging with glTF-CSharp-Loader?

[bghgary]

5. What is the future plan for merging with glTF-CSharp-Loader?

same things that glTF-CSharp-Loader is doing, but with optimized hand written JSON serialization/deserialization

Is it possible to generate the optimized JSON serialization/deserialization code? If so, I'm thinking we can modify glTF-CSharp-Loader to generate this optimized code instead of relying on reflection.

1. GLTF Serialization/Deserialization project namespace (Ex. GLTF)

Ideally, I think I would separate the serialization/deserialization from the classes that define the schema. I prefer a namespace with the word Schema on it (e.g. GLTF.Schema) for the schema. The glTF-CSharp-Loader uses glTFLoader.Schema. The serialization/deserialization code can use extension functions in a namespace with the word Serialization (e.g. GLTF.Serialization).

[robertlong]

Some of our meeting notes from today (@robertlong, @stevenvergenz, @sbtron, @bghgary, and @MSblgross in attendance)

We decided on the following:

1. GLTF Serialization/Deserialization project namespace (Ex. GLTF)
   GLTF for the glTF serialization/deserialization/schema project and GLTF.Schema for all the schema classes.
   UnityGLTF for the Unity glTF import/export project.

2. Unity Import/Export project namespace (Ex. UnityGLTF)
   We'll likely add this when we split the importer and exporter into classes. Still TBD.

3. Should we split the repositories now or keep them in folders in this repo like they are in Initial architecture update #50

4. If we split the repositories, what should we name the Serialization/Deserialization project (Ex. glTF-CSharp)

5. What is the future plan for merging with glTF-CSharp-Loader?
   We're going to keep both projects in the same project for now and work on adding generation of optimized serialization/deserialization code to glTF-CSharp-Loader. Additionally we will move any helper classes to this project.