こちらが、UniGLTFというVRMを扱うプラグインからGLBを出力する機能で出力したsparse accessorを有効にしたGLBと、未使用のGLBのサンプルデータです。
sparse accessorを有効にしたデータを読み込むとメタセコがクラッシュする場合があります。

（glTF-Validatorではどちらのデータも問題なしですが、khronos公式のglTFサンプルビューアーでエラーとWindows標準の3Dビューアーではクラッシュ）

UniGLTFという機能から、エクスポートを行ったところVRMとしてエクスポートされてるデータとはまた異なる壊れ方をしてるので、一旦これらのサンプルデータを元に検証を行ってもらえればと思います。

https://github.com/vrm-c/UniVRM/files/9934212/GLB_sparse.accessor_testzip.zip

VRM1_Constraint_Twist_Sample.glb
VRM1_Constraint_Twist_Sample_sparse accessor.glb（sparse accessor）

一応、出力元の環境の方でもissueを立てて検証を行ってます。
https://github.com/vrm-c/UniVRM/issues/1906#issuecomment-1302807143

参考画像：
sparse accessor無し
https://user-images.githubusercontent.com/26161297/199865017-515152d3-df3d-412f-aeda-f40ca733d121.png
sparse accessor有り（ブレンドシェイプが壊れる）
https://user-images.githubusercontent.com/26161297/199865315-0ce15992-4ee0-44e6-87ff-a6fd3a9c8c00.png
VRM1として出力されたGLBデータ（ブレンドシェイプに変化がない）
https://user-images.githubusercontent.com/26161297/199834633-775ed22d-833a-4253-ac1d-121f8051254e.png

以下の参照画像が間違っていました。
＞VRM1として出力されたGLBデータ（ブレンドシェイプに変化がない）
正しくはこちらとなります（変化がない状態）
https://user-images.githubusercontent.com/26161297/199830946-703ddb7c-2e68-46f8-b48a-51a8c0724efd.png

sparse accessorについては公式のサンプルもほぼ用意されていなく、実データを見たことがなかったので、対応はしていません。
用意いただいたデータを試しに読み込んでみたのですが、データが破損しながらもその他の部分は読めることもあるようですが、異常終了してしまう可能性もあるので、sparse accessorを含むデータだと予め分かっている場合は読み込まないようにしてください。

今後のリリースで対応を検討します。

なるほど、そういう経緯だったのですね。
対応検討ありがとうございます。
宜しくお願いいたします。

sparse accessorの公式サンプルがあったので、他のデータと一緒に参考になればと思います。

https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/SimpleSparseAccessor

とりあえずVer4.8.4aで対応したつもりですが、テストしたデータ数
が少ないため対応が十分かどうか正直なところまったくわかりません。
何かおかしな点などありましたらまたよろしくお願いいたします。

対応ありがとうございます。
早速、Ver4.8.4aで確認してみました。


https://github.com/vrm-c/vrm-specification/tree/master/samples/VRM1_Constraint_Twist_Sample/vrm

上記のVRM1としてsparse accessorが有効になっているデータを、拡張子をGLBにしてインポートしてみたところ正常に読み込めているのを確認しました。
ただ、インポートしたデータをそのままGLBとしてエクスポートして再度Metasequoiaで読み込もうとすると「ファイルの読み込みに失敗しました」というエラーが出て正常に読み込めないので確認していただけるでしょうか。
一旦、MQOファイルとして出力してからそのMQOを開きなおしてGLB保存しても同様のエラーが出て読み込めないGLBファイルとなってしまうようです。
https://github.khronos.org/glTF-Validator/
こちらのの、glTFValidatorを通すと以下のエラーが出ます。Blenderでも同様のエラーが出て読み込めないファイルが出来上がってしまうようでした。
>Invalid JSON data. Parser output: FormatException: SyntaxError: Expected double-quoted property name in JSON at position 75983


https://github.com/vrm-c/UniVRM/files/9934212/GLB_sparse.accessor_testzip.zip

一方で、こちらのUniGLTFから出力されたsparse accessorのデータを同様に、インポートしGLBで保存して再読み込みしたところ問題なく読み込めているようです。
こちらでは、glTFValidatorではエラーは出ませんでした。



両者の、インポートによる状態の違いエクスポートされたデータの違いを確認していただけるでしょうか。

調べたところ、どうもConstantシェーダがあるとエラーデータが出力されてしまうようです。
glb内にunlit拡張が指定されているとインポート時にConstantシェーダとなるのですが、その状態で出力するとダメという状況です。

調査の方ありがとうございます。
この問題はつまり、unlit拡張情報を持つglTFを読み込むとConstantシェーダーになるということはその拡張情報があるかぎりConstantシェーダーで出すと必ずエラーになるということですよね。
ということは、シェーダーを変えれば問題がなくなる。
Constantシェーダーとの相性問題？なのでしょうか
そのような状態のデータをインポートしたとして、エクスポート時にエラーデータにならないように対処するというのは可能でしょうか？
手動でシェーダーを変えることは勿論できますが、glTFの持つ情報を維持していた場合必ずエラーのデータが出るというのは自動で回避できないものかなと思うのですが如何でしょうか

この問題は、Constansシェーダーとの何がエラーデータの引き金になっているのでしょうか？自分の認識ではConstantシェーダーというのはメタセコイア独自のシェーダーで外部へエクスポートする際にシェーダーそのものがエクスポートされるわけではないので問題が無いと認識していました。

どのバージョンからか不具合でおかしくなってしまったようで、Constantシェーダだとエラーになるので、現状では回避のために他のシェーダに切り替える必要があります。

修正版を出す予定ですが、リリースに若干手間がかかるので、どのタイミングで出すか決めかねています。glTF周りは割と注力しているので、早めに出したいところではあるのですが…

返答ありがとうございます。
対応いただけるとのことでありがたいです。
私的にはタイミングは、開発者様の都合がいいタイミングで大丈夫です。

Ver4.8.4bでConstantでも問題なく出力できるよう修正しました。
ついでに、unlit拡張が含まれるファイルを入力した場合、そのままglTFシェーダの非照明がオンになるよう仕様変更もしています。

対応ありがとうございます。
追加で行ってくれた、.vrmファイル拡張子への対応が直接インポートできるようになったのでとてもスムーズに読み込みできるようになりました。
エクスポートして検証を行ってみました、コンスタント状態でエクスポートしてMetasequoia ver4.8.4bでの再読み込み、glTFValidatorでのエラーが無い状態、Blenderでの読み込み、UniGLTF環境での読み込みで問題が無いのを確認できました。

対応ありがとうございます！