Binary MC for 1.0

[andreasplesch]

I just noticed the samples wanted label in #109, so here we go.

[emackey]

Maybe use an npm dependency instead of a user-specific path here?

[andreasplesch]

I was following the style of the existing convertAll.sh script.
Perhaps just remove the script to avoid confusion ?
Since I am unsure how to use an npm dependency here, I just commented the alias and added an explanation.

[andreasplesch]

The script is bit more complicated/strange because gltfpipe insisted on its 'output' directory.

[andreasplesch]

If there is anything I can help with, I would be glad to.

[emackey]

Hi @andreasplesch, sorry this fell through the cracks. I don't think much/any effort is being put back into 1.0 now that glTF 2.0 is in full swing. I don't think we need to include more permutations of 1.0 models here. Also I'm mildly opposed to just automatically applying all permutations of extensions to all models; instead I think it would be more useful to have a specific example of each Khronos-ratified extension, showing how that extension is best used for some purpose that a core glTF model can't replicate.

[andreasplesch]

cx20/gltf-test#17
was the starting point for this PR since gltf-test would only accept gltfs from this repo.
At the time binary MC was the most compact encoding not requiring packaging of shaders.
If the glTF 2.0 MC extension stays in limbo, glTF 1.0 plus MC may be of more long-lived interest to some communities.
So, to me, being inclusive has more benefits than drawbacks. What is the concern ?

[emackey]

I'll admit I haven't been following MC very closely, but I think the current work is being done in KhronosGroup/glTF#1163.

My concerns here are, in no particular order:

• We want to keep the spotlight on glTF 2.0, not 1.0. New users might be diverted from 2.0 by seeing new models getting added to the 1.0 set.
• Sample models with textures take a lot of space relative to what Git is normally used to store, so space can become an issue.
• Having those models here implies Khronos is actively maintaining them, which is questionable now even for the existing 1.0 sample set, let alone new entries. I suspect the existing set will only remain as a historical artifact, not an actively curated collection.

Sorry for raining on the parade. But I think it's best to focus our efforts on making sure that 2.0 and its extensions can be made to cover use-cases that 1.0/MC used to cover.

(@cx20 feel free to chime in if you have opinions on this too, thanks!)

[lexaknyazev]

JSYK, 1.0/MC has never been finished.
I'm not even sure that existing draft implementations agree with each other.

[andreasplesch]

Oh well, so be it.