Arseny Kapoulkine

> Since v0 support is not going anywhere (because the EXT extension has been ratified and tools are expected to accept such files indefinitely), I'd suggest allowing v0 in KHR...

Separately: Should the filter decoding be bit exact? As far as I can tell, there's parts of glTF specification that do not require bit exact decoding - for example, normalized...

Updated the spec as suggested, including adding v0 back to the extension text. The bitstream reference now specifies cases where aspects of the encoding depend on the version (different tail...

I've drafted optional support for this in gltfpack as well (making it trivial to produce test assets that use the full set of features, not just a renamed EXT ->...

Here's a couple test assets converted with the PR above; they aren't necessarily super representative, but this makes it easy to test renderer support. Asset | Size | Attribute size...

We now have a few outstanding draft implementation PRs (gltfpack https://github.com/zeux/meshoptimizer/pull/966, glTF-Transform https://github.com/donmccurdy/glTF-Transform/pull/1745, three.js https://github.com/mrdoob/three.js/pull/32163). For some of them to get merged, it would be great if the status of...

@lexaknyazev Thanks! I agree with this list of recommendations; they match my plans for meshoptimizer library (indefinite transparent support for decoding v0/v1 and indefinite support for encoding v0/v1 based on...

> But this implementation is certainly not independent of the other. Both are still written by the same author. That's not entirely correct; the original version was written from the...

My understanding is that this would be independent of this PR, and would belong in glTF-Sample-Assets? That repository has a couple EXT_ assets and it should be easy to replicate...

> Right but that's one of the conditions for marking an extension a Release Candidate. The sequencing here isn't super clear to me; what status is this extension in right...