Update BrainStem and DragonAttenuation to KHR_meshopt_compression

[zeux]

Specification: KhronosGroup/glTF#2517

The updates are performed by converting the source models with gltfpack 1.0, using -cz for DragonAttenuation and -cz -vpf for BrainStem (consistent with the original conversion settings), and post-processing the glTF files using jq as a pretty-printer.

The resulting files render the same, but require the viewer to support the KHR variant of the extension. While this is typically very easy to do (see mrdoob/three.js#32163 for example), as of this PR no viewer supports it yet, so we may want to wait to merge this until a couple viewers get the KHR support.

The updated files here are not using fallback buffers so the extension is required; see MeshoptCubeTest model for a more complex and varied set of tests that exercise the JSON structure more broadly, this PR is focused on updating the more real-world models so that we have both a synthetic test version and a more realistic one.

[javagl]

Having these models somewhere is good, and I see the reasoning from the context of the discussion at KhronosGroup/glTF#2517 (comment) (~"there must be sample models for the ratification")

But... (probably mainly @lexaknyazev , but also the other "usual suspects") :

Should the original EXT meshopt versions be retained?
(I.e. should the new ones be added in a new directory?)

I'm leaning towards keeping the original ones, and adding the new ones. This mainly rooted in ... certain aspects that may not have been thought through back when the structures here have been established:

• The directory name glTF-Meshopt gave a very prominent role to meshopt. People could expect this to contain an EXT meshopt model. They should be able to rely on this
• There is no indication about which meshopt version is used for these models. People could try to load such a model with a loader that supports EXT, but that loader will fail, because it's KHR now.
• And in hindsight, one could make a case to not assign such a special role to one extension, by using a short form of its name in the directory name. Not sure whether glTF-SOME_example_extension would have been better, but ... it is the way it is now.
• More broadly: We'll have to think about a better handling of extensions (and "categorization by extensions") here...

[lexaknyazev]

Agreed that original EXT variants should be preserved (even if renamed); deferring to @DRx3D on the directory structure.

[lexaknyazev]

I think we could rename the old directory to glTF-Meshopt-EXT and call the new directory glTF-Meshopt-KHR (putting the extension prefix at the end preserves the sorting order in UI).

[javagl]

That sounds reasonable.

Iff this is done (whoever is responsible for the final 👍 or 👎 on that...), then the directory from #257 should also be called glTF-Meshopt-KHR for consistency.

[zeux]

One possible alternative I was considering yesterday but didn't suggest is glTF-Meshopt-EXT & glTF-Meshopt. I think in general I'd expect that the two models updated in this PR are the only models in this repository that use the EXT variant (because for any new model addition it's not clear why EXT variant would be added), so using a shorter name would be descriptive enough long term. But I'm fine with either option.

[UX3D-haertl]

I'm not sure why this is not visible in the diff, but it seems like the URI to the checkerboard image in the DragonAttenuation asset changed from .png to .jpg

glTF-Sample-Assets/Models/DragonAttenuation/glTF-Meshopt/DragonAttenuation.gltf

Line 208 in c512ccf

"uri": "checkerboard.jpg"

But the image itself is still a .png file. Therefore, I get an error while loading this in sample viewer.

[DRx3D]

@javagl :

I think we could rename the old directory to glTF-Meshopt-EXT and call the new directory glTF-Meshopt-KHR (putting the extension prefix at the end preserves the sorting order in UI).

Does this request mean all assets that use extensions need to include the extension name and prefix or would this only apply when the asset comes in different flavors by using different extension(s)?

[lexaknyazev]

@DRx3D IIRC, we decided to use glTF-Meshopt for the new KHR variant and glTF-Meshopt-EXT for the old EXT assets.

[zeux]

@UX3D-haertl Thanks! This is because my branch was based on an older version that used JPG files but they were later changed to PNG. The resulting conflict is silent as the relevant portions of the file didn't change.

I will update this PR to rectify that and also rename the old files to glTF-Meshopt-EXT.