Kota Iguchi

Sorry for interrupting but I'm interested in this too. I'm guessing ozz may be able to support `weights` animation channel in order to support morph target animation in glTF, I...

* Yes, what I was talking about is `weights` that's stored in glTF [animation channel](https://github.com/KhronosGroup/glTF/blob/main/specification/2.0/schema/animation.channel.target.schema.json#L26) * There is tutorial from Khronos- [A Simple Morph Target](https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_017_SimpleMorphTarget.md#a-simple-morph-target) * Sample models - [SimpleMorph](https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/SimpleMorph),...

同感です。我田引水ですが似たようなニーズから #214 にて、 VRM 作成に使われたオリジナルデータに対して破壊的変更をしないようにという提案をしています。破壊的変更をしないことでメッシュの削減など自動変換をかける際にも役立つではないかと思っています。 サブセット規格に関してですが VRM 1.0で `MSFT_lod` という複数の Levels Of Detail (メッシュのクオリティ）をひとつのファイルにまとまられる機能について話題にはされていた気はします。 `MSFT_lod` だとファイルサイズが増える欠点があるので個人的には自動変換を推します。 これまた我田引水ですが自動変換に関しては SEED などでやっている メッシュ削減と似たようなことを拙作 [vrmpack](https://github.com/infosia/vrmpack) で実現できることを確認しているので、こういうものを各種サービスで独自に実装するのではなくて VRM-C として標準実装を提供してユーザ側もしくはサービス提供側で簡単に削減してもらえるようにできるといいのかもしれません。

> 実はclusterでもVRM reduction技術の開発中で > その上で、reducerのreference実装が公式に提供されているのは望ましいとは思いますが、必須だとは思いません。 素晴らしいことなのですがこれはつまり VRM エコシステムを構成する主要メンバーであるところの VRoid、SEED ONLINE、cluster の各サービスがそれぞれ別の reduction を実装していることになるということで...こうなると何か各社フィードバックをして公式実装が可能なのではないかとか期待してしまいます :sweat_smile:

cluster が LOD に対応したということで感服して [色々見てみているのですが](https://twitter.com/search?q=cluster%20LOD&src=recent_search_click&f=live) 例えば 3万ポリゴンのモデルを 2,000 とかに自動で落とすとかはアルゴリズムではなかなか厳しいのかなという印象を持ちました。。モデルの形状を崩さずに削減するのは例えば [vrmpack](https://github.com/infosia/vrmpack#simplification)だと 3万→5,000くらいが限界という印象です。 VRM に `MSFT_lod` があるといいのかもしれないですね。

そうですね、10 段階の LOD level となるとしんどそうですが例えば容量の大半を占めるテクスチャを共通化させる前提で 3,000 tris など最低限表示が崩れないレベル１つだけにするというような縛りにできれば、MSFT_lod もそれほど非現実的ではないのかなあという印象を持っています。例えば手元の VRoid モデル (35,000 tris 26MB) からマテリアルを削除して 4,000 tris 程度に落とした glb を作ってみたのですがファイルサイズは 1MB ほどでした。独立した glb ファイルでこのサイズなので実際にはもっと削減できるのではと期待しています。 とはいえ、MSFT_lod 対応は今より圧倒的に複雑になると思いますし、仮にハードウェアやロジック等の改善で 5,000 tris 程度に自動リダクションできるのであればそれが一番良いと思います 😄

Unity 以外のゲームエンジンでゲームやアニメーション用途での VRM 使用を検討しているのですが、ここまでの議論を拝見すると TokageItLab さんやしげぽんさんの仰る通り今後様々な用途での VRM 利用を考えるとボーンのローカル軸を破棄する仕様には無理があると考えています。破棄するのではなく glTF の拡張情報として正規化に必要となる情報を持たせる案に賛成です。 VRM の思想としてルックの一貫性・ポータビリティを担保したいという意図はわかりますが、情報が破棄されると元に戻せないのが問題だと考えています。 glTF の拡張情報として正規化に必要となる情報を持たせて、VRM の仕様としては正規化されたデータを見てください、という仕様では駄目でしょうか？

本件と関連して #214 を新しい issue として追加しました。メッシュやボーンの情報などソースとなる3Dデータに対する破壊的変更に関連して VRM としてより広い思想の転換が必要かと思い問題提起させていただきました。VRM に必要な情報は VRM の extension として格納すべきだというのが私の意見です。

本件 #214 のような根本解決を望みますが、とりあえず影響範囲が少なそうな折衷案としてはアドホックですが『元の姿勢がどうであったか』という情報だけ追加プロパティとして持たせるというのはとりあえずの対策として（_根本解決を何年も待つよりは_）考えていいのかもしれません。回転だけバッファに格納すれば追加サイズは１ノードにつき `sizeof(float) * 4` とちょっと、基本ノードの構造は VRM 0.x との互換性を保っているので既存プログラムの変更は必要なし、ローカル軸の表現が重要になってくるユースケースや Unity 以外のゲームエンジンで必要な場合だけそこを見ればいい、という感じです。こういう感じでプロパティを追加していくのは無秩序な仕様の肥大化を招きそうでよくない感じがしますが... #214 を待っていると何年もかかりそうなので案として俎上に載せたいと思います。

その資料拝見しています。この issue を書く際にその JPG の例を出そうか迷っていたのですが、VRM は最終出力であるという前提、元の情報が欠落してもよいという考え方、現状すでにそこが破綻していると思います。#34 で示されている問題は、JPG と PSD で例えるならば、JPG へのコンバートによって失われた情報を無理に再現しようと試みて失敗している状態だと考えます。UniVRM で複数回正規化するとうまくいかない、というような問題も同じ理由からではないかと思っています。VRM は glTF の正式 extension を目指していると聞きますが、glTF の考え方からすればVRM の構築に必要な情報はシンプルに VRM の extension で処理すべきものであり、ソースのメッシュやボーンなどの情報を壊すことにどうしてそこまでこだわるのかな、というのが純粋な疑問です。