s-iwaki-d

みなさまご意見ありがとうございます VRM 1.0についてはほぼ固まってきており、「まずリリース」のフェーズに入っていると考えています。ここからのさらなる機能拡張や大幅な変更は想定しておりません。 ドキュメントの不備に対しては認識しており、現在必要なドキュメントの洗い出しを進めております。 実行環境については次回リリースからUniVRMのサンプルビューアのビルドも同時に公開していくことを検討しております。 こういった技術仕様外のドキュメントやテスト環境などについては課題として今後改善していきますのでよろしくお願いいたします。

- BlendShapeだけでいいのか。Bone実装もありえるのではないか - 呼吸の間隔はキャラクターによって異なるのではないのか。小さいキャラクターは呼吸がはやかったりするのではないか。個性はアニメーションパターンだけでは表現できないのではないのか といったところが課題として考えられ、簡単には決められなさそうなのでいったん未来の課題とします

その資料で言う「ファイルが１つで完結する」というのはオリジナルのデータをすべて保持し続ける、という意味ではありません。同資料のp30もごらんいただきたいのですが、VRMはあくまでも編集用ファイル（オリジナルの情報を保持するためのファイル）ではなく出力用ファイル（データを利用するアプリケーションにとって都合がよい形式のファイル）を想定しています。  「１ファイルで完結すべき」というのは利用者が各種アプリケーションにアバターを持ち込む際に１ファイルだけ食わせればアバターとして使えるようになるべし、という話であって、１ファイルにすべての情報を保持しすべてのアプリケーションで編集可能状態を維持するのは目標とするところではありません。その用途であればfbxでいいのではないでしょうか。 そのためたとえばPSDからJPEGにエクスポートする際に画像に破壊的変更が加わるのと同じように、VRMにエクスポートする際に構成がアプリケーションに利用しやすい形で変更が加わることは自然だと考えています。 それと「その変更の過程でクリエイターの意志を伝えることが仕切れていない」という課題は直交した概念であって、何がどう足りないのか、それは仕様に落とし込むべきかどうか、を別途検討するべきです。

まず、オリジナルデータを「破壊」するかどうか、というのは規格の話ではなく実装の話かと思います。 規格としては現在のところ、ボーンに回転を入れない、やTポーズである、などといった**制約**として定義されています。 ここで「破壊」とされているのは、その規格上の制約にそぐわないデータを制約にあわせるように変換しようとするExporter実装上の手順のことを指していると理解しています。 もともと規格に沿った形でモデルデータが定義されていればそのまま出力すればよいわけで、それは元のデータを破壊することにはなりません。 これに対して ・Exporterが本来の規格上の制約以上にデータをいじってしまう ・定義された規格上の制約が必要以上に厳しくクリエイターの意思が反映できない というような議論であればわかりますし議論されればいいと思うのですが、 本issueは ・VRMは「拡張」のみを取り扱うべきであってglTFに対しての「制約」は許されない という提案であると解釈しました。それはさすがに飛躍が過ぎるのではないでしょうか。