Extract glTF utility to its own project.

[SimonDarksideJ]

XRTK - Mixed Reality Toolkit Pull Request

Overview

PR to extract the glTF utilities in to their own project.

Having a specific gLTF library within the XRTK restricted used from using their own glTF libraries and binds XRTK to tightly on a single glTF solution.

This PR simple removes the current glTF solution and moves it to it's own optional repo

Changes

• Fixes: Remove current gLTF utility #800

Breaking Changes

• Breaks
• Only breaking change is that this removes the native ability to load glTF controller models directly. This feature should be refactored to be more open.

Related Submodule Changes

• glTF dependencies move to a separate project Examples#34
• https://github.com/XRTK/glTF/tree/development
• Remove glTF loading from WMR package com.xrtk.wmr#126

[StephenHodgson]

See comment

[FejZa]

My question would be, why does XRTK needs its own implementation of glTF / its own glTF module? This is something I haven't been using at all yet and thus can't really judge.

So why do we need this and what is the resolution for this PR?
@StephenHodgson "Can we at least provide a game object to instantiate?" can you explain what you mean? We are already creating a game object for each controller aren't we?

[SimonDarksideJ]

My question would be, why does XRTK needs its own implementation of glTF / its own glTF module? This is something I haven't been using at all yet and thus can't really judge.

The separate implementation is simply another variant on the Khronos implementation but updated to use Unity JSON and a host of other improvements. I think it's worth preserving and maintaining in its own repo. But being separate means you can use your own if you wish instead.

So why do we need this and what is the resolution for this PR?
@StephenHodgson "Can we at least provide a game object to instantiate?" can you explain what you mean? We are already creating a game object for each controller aren't we?

That's what confused me, just hadn't had the time to circle back to this conversation. Any further thoughts @StephenHodgson ?

[StephenHodgson]

Yes this is true, for edit time, but if we have a 3rd party glTF importer it'll likely pass a GameObject reference as either the instantiated object or an object to insatiate. I suppose that's what I'm looking for exactly. Just to link the references up (if the object has already been created) or to create it for us if it's not already in the scene.

[FejZa]

Fair enough, now I get it.

[SimonDarksideJ]

but if we have a 3rd party glTF importer it'll likely pass a GameObject reference

@StephenHodgson As commented above, you don't need a GameObject reference, just write your own Visualizer to load the glTF model and set the Visualizer type to your new visualiser for the controllers you want to configure.

[StephenHodgson]

What is failing the build?

[SimonDarksideJ]

What is failing the build?

Just checked, it's complaining about the Examples project. I'll do a quick PR to also remove the glTF samples from there

[SimonDarksideJ]

Pushed an update to change the branch for examples and the recent comments
XRTK/Examples#31

[SimonDarksideJ]

@StephenHodgson Issues resolved

[StephenHodgson]

Let's keep the glTF examples and just update the references

[StephenHodgson]

@SimonDarksideJ let's be sure to create a issue in WMR for adding the visualizer later on once the glTF package is published.