vrm-c
Policy Change: Avoid destructive change on source mesh/bone structures
※infosia 追記 誤解を招く文章になっているかもしれません、こちら から始まるスレッドに言いたかったことがまとまっているのでそちらもご参照ください
When you export VRM, the structures of source meshes and bones have been casually altered and these kind of destructive changes against original data have been usually accepted by the name of "normalize", "freeze" or "bake" (See #34 and #205). This might be considered UniVRM issue but I think this has been a kind of policy behind VRM. I would argue that we should avoid these kind of destructive changes on the original model data unless there is very clear and obious reason to do that and there's no way to avoid it. Instread of destroying source data, glTF extension area should be used to store the data of how VRM treats the data. There should be much information stored in the extension area that VRM exporter and importer can construct by refering them accordngly. The reason because destruct changes on original model data are harmuful is pretty obious - you can not recover original data when you destroy it. I saw VRM has a policy that VRM file should have "complete data" to describe 3D avater (p24 @ slide at Unite Tokyo 2019) but these destructive change breaks it and the complete artifacts are lost needless to say meshes and bones are critical parts of the shape.
VRM をエクスポートする際にメッシュやボーンの情報などソースとなる3Dデータに対する破壊的変更が行われますが、その際にオリジナルのデータを破棄してもいいという思想を転換できませんか？オリジナルのデータを破壊するのではなく、そうすることが自明な場合やどうしても避けられない場合を除き、VRM に必要な情報は glTF の extension に格納するべきです。 また、このことはエクスポータを実装する際の VRM 仕様もしくはポリシーとして宣言すべきと思います。 オリジナルデータを破壊するともとに戻せないのが問題です。 #34 の議論も合わせて参照ください。ソースに対する破壊的変更は (p24 @ slide at Unite Tokyo 2019) で表現されるような、『VRM は一ファイルで完結できるべき』という基本思想に反しています。#34 で議論されているようにソースのボーン角度などにはモデル作者の意図があり、これを破壊することは『クリエイターの意志を伝える』という VRM の思想にも反するものと考えます。
VRM の仕様としては現状オリジナルデータの扱いをどうするかという規定はないため UniVRM のイシューとして提起するか迷いましたが、オリジナルのデータに対する破壊的変更が VRM フォーマット定義にかかわる方々に思想として広く受け入れられていると思い、VRM の問題として提起することにしました。
破壊的変更を glTF データの本体部に持たせている理由としては、インポート時に glTF データの本体部に対しての処理を行いたくないという理由がありそうですが、だからといって破壊的変更を本体部に適用した物を標準とするのは良くないと考えます。
よく問題として挙げられる、
- 再編集が困難
- Unity 外での利用が困難
これらの原因がその破壊的変更にあるように私は考えており、現状では Unity Humanoid 専用フォーマットから脱却する事は難しいと考えております。
その資料で言う「ファイルが１つで完結する」というのはオリジナルのデータをすべて保持し続ける、という意味ではありません。同資料のp30もごらんいただきたいのですが、VRMはあくまでも編集用ファイル（オリジナルの情報を保持するためのファイル）ではなく出力用ファイル（データを利用するアプリケーションにとって都合がよい形式のファイル）を想定しています。
「１ファイルで完結すべき」というのは利用者が各種アプリケーションにアバターを持ち込む際に１ファイルだけ食わせればアバターとして使えるようになるべし、という話であって、１ファイルにすべての情報を保持しすべてのアプリケーションで編集可能状態を維持するのは目標とするところではありません。その用途であればfbxでいいのではないでしょうか。
そのためたとえばPSDからJPEGにエクスポートする際に画像に破壊的変更が加わるのと同じように、VRMにエクスポートする際に構成がアプリケーションに利用しやすい形で変更が加わることは自然だと考えています。
それと「その変更の過程でクリエイターの意志を伝えることが仕切れていない」という課題は直交した概念であって、何がどう足りないのか、それは仕様に落とし込むべきかどうか、を別途検討するべきです。
アプリケーションに利用しやすい形で変更が加わる
@s-iwaki-d 現在の破壊的変更によって Unity 以外のアプリケーションでの利用が困難であるという現状が #12 や #34 で示されていると思うのですが、これは「 Unity アプリケーションにおいて利用しやすければよい」という意図で決められたコンセプトなのでしょうか。
JPEG の破壊的変更はあくまで圧縮であり、画像としての意図は伝わるだけの情報は残っている一方で、 VRM の正規化処理は明らかに元の情報が欠落しており、 圧縮と同等のように考える事はできないと思います。
その資料拝見しています。この issue を書く際にその JPG の例を出そうか迷っていたのですが、VRM は最終出力であるという前提、元の情報が欠落してもよいという考え方、現状すでにそこが破綻していると思います。#34 で示されている問題は、JPG と PSD で例えるならば、JPG へのコンバートによって失われた情報を無理に再現しようと試みて失敗している状態だと考えます。UniVRM で複数回正規化するとうまくいかない、というような問題も同じ理由からではないかと思っています。VRM は glTF の正式 extension を目指していると聞きますが、glTF の考え方からすればVRM の構築に必要な情報はシンプルに VRM の extension で処理すべきものであり、ソースのメッシュやボーンなどの情報を壊すことにどうしてそこまでこだわるのかな、というのが純粋な疑問です。
追記します。
この issue は VRM が fbx を目指すことを提案するものではなく、何もかもを VRM に詰め込んで欲しいと要望しているものではありません。「VRM のことは VRM のエリア (extension) で処理してほしい」という基本的な考え方を提案するものです。
「 Unity アプリケーションにおいて利用しやすければよい」という意図で決められたコンセプトなのでしょうか
（追記）※以下は議論が散漫になりそうなので消させてください。
~~別トピックになるかもしれませんがここも気になっています。現状の 0.0 バージョンで Unity での利用のみが考慮された仕様になっているのは仕方ないことかと思いますが、VRM コンソーシアムがスタートして（詳しくは存じませんが）２年近く、 #34 が投稿されてから１年以上経った状態で、（追記：技術的に非常に難しいことを要望しているわけではないのにも関わらず、）まだスキーマも決まっていない 1.0 仕様でこの問題が特に理由を示されず対応なしとされるということは、Unity 以外のゲームエンジンでの利用についてあと何年必要なんだろうと考えてしまいます。~~
まず、オリジナルデータを「破壊」するかどうか、というのは規格の話ではなく実装の話かと思います。 規格としては現在のところ、ボーンに回転を入れない、やTポーズである、などといった制約として定義されています。 ここで「破壊」とされているのは、その規格上の制約にそぐわないデータを制約にあわせるように変換しようとするExporter実装上の手順のことを指していると理解しています。 もともと規格に沿った形でモデルデータが定義されていればそのまま出力すればよいわけで、それは元のデータを破壊することにはなりません。
これに対して ・Exporterが本来の規格上の制約以上にデータをいじってしまう ・定義された規格上の制約が必要以上に厳しくクリエイターの意思が反映できない というような議論であればわかりますし議論されればいいと思うのですが、 本issueは ・VRMは「拡張」のみを取り扱うべきであってglTFに対しての「制約」は許されない という提案であると解釈しました。それはさすがに飛躍が過ぎるのではないでしょうか。
定義された規格上の制約が必要以上に厳しくクリエイターの意思が反映できない
ローカル方向を全て Quat(0,0,0,1) にするというのはこちらに該当していると考えます。こちらは定義の話でもあるので引き続き #34 でも議論を続けます。
メッシュの破壊に関しては詳細は存じ上げませんが、何かしらの要員でポリゴン数が入出力時に変化するという話を耳にした事があります。（Nゴンの除去等？）何かしらの処理が入るのであればその旨を記述すべきであると考えます。
もともと規格に沿った形でモデルデータが定義されていればそのまま出力すればよいわけで ・VRMは「拡張」のみを取り扱うべきであってglTFに対しての「制約」は許されない という提案であると解釈しました。それはさすがに飛躍が過ぎるのではないでしょうか。
許されないというより『そうすることが自明な場合やどうしても避けられない場合を除き』という提案です。VRM の理想・取り組みは確かに野心的だとは思いますが、現状はどうでしょうか。VRM に対応したエクスポータがいくつあるでしょうか？assimp や cgltf などの著名なインポータが VRM に対応しているでしょうか？Unity ゲームエンジン以外での実績は？VRM の仕様が日本以外でどのように受け止められているでしょうか？この辺は「私はそうは思わない」という議論になればもうそれまでですが「こうあるべきだ」という理想は色々あるだろうとは思いますが Unity 以外でのゲームエンジンでの利用、UniVRM 以外でのインポータ/エクスポータへの対応を考えると、VRM を glTF の extension の一つとしてとらえた方が広く受け入れられると考えているので、上記の提案をしています。
編集容易なオリジナルデータをVRMで表現できるようにVRMを拡張していくべき、という考えには明確に反対します。
まず、前提として、アバタークリエイターの使う編集フォーマットは多岐に渡ると考えられます (e.g. 単なるメッシュ+シェーダーパラメーターではなく、Marvelous DesignerやZBrushのような布やボリュームを扱う表現など)。それをVRMフォーマットに含めていくことは際限ない仕様の肥大化を招き、#217 のようなreductionを中心とするエコシステムが(開発工数の増加で)成立困難になってしまうと危惧しています。また、中途半端なサポートを標準として提供することは、結果的にアバタークリエイターの自由度を損なうと考えます。この状況の中で、「元のbone local transform保持だけならOK」というような線引をしていくのは難しいと考えており、「VRMをミニマムに保つ」という原則を実行していくほうが実効性が高く思えます。
@s-iwaki-d の述べているように、編集可能形式は別フォーマット(それはもしかしたらVRMを拡張したものかもしれない; ただしそれはVRMコンソーシアムの守備領域では現状無いと認識しています。いかがでしょうか？)で実現されるべきと考えます。
非VRM glTF exporter / importerとの互換性について
アバターエコシステムの将来像として、メッシュデータをモデラーが手で作る、というのは基本として存在しつつも、多くのユーザーはよりアバターに特化した簡易な編集UI (e.g. たとえば服の着替えや髪型変更など)を使っている状態になると予想しています。(実際VRoid StudioやREALITYはそのようなUIを提供しています。) importer側でも、importer/exporterというより、アバターを利用するサービス内で着替えられる、というような統合された体験が主体になっていくと考えています。
このとき、アバター非対応の汎用glTFエコシステムの寄与があまりあるとは考えられず、それよりは、アバターフォーマットとしてのVRMをミニマムに保つことで、結果的にアバターエコシステムの構築が加速されると考えています。(それはそれとして、VRMの非extension部分をglTFのstrictなsubsetに維持することは実装上のメリットが大きいと思います。)
実際clusterではすでにproduction環境でgo言語によりVRM validationを実装しています。VRM仕様の肥大化は実装工数増大によって、実質的に特定言語の公式実装(現状ではUniVRM)への依存を増す方向に作用するため、それはVRMのポータビリティの理念に反すると思います。改めてclusterとしては、実行時に表現されるアバターのリッチさを増やさない(=編集容易性のための)仕様肥大化は歓迎しないという意見を表明します。
少し勘違いされておられるかもしれませんが、こちらはモジュールを追加するかどうかの議論ではなく、タイトル通り、元のメッシュやボーンに対しての変更を破壊的に行っている事に対する問題提起です。
簡単に言えばボーンやメッシュに対する変更をエクスポート時に行う必要があるのかという問題になります。例えばメッシュ割りを変更するのであればその差分のデータ、ボーンの方向を変更するのであれば変換行列を VRM 拡張部分に記録し、元の glTF に対しての破壊的変更を減らすという実装は可能ではないでしょうか。
個人的には現在の破壊的変更により一般的な glTF モデルとして扱う事が困難になっているのが問題だと考えているので、一般的な glTF モデルとして扱う事ができるような定義が実現できていれば問題ないとは考えていますが、現状そうではないので議論を行っています。ミニマルであるべきであるというコンセプトには異存ありませんが、汎用 glTF としてはどうでもよいという意見には賛同できません。 glTF としての汎用性を失った結果プラットフォームの寡占化を招く事になりますし、それは VRM 1.0 のプラットフォームを超えた汎用フォーマットというコンセプトに反するのではないでしょうか。
みなさんありがとうございます この issue もう閉じてしまおうかと考えていましたが盛り上がってよかったです。 私の書き方が悪かったと思うのですが誤解されやすいようなので再度書いておきます。
この issue は VRM が fbx を目指すことを提案するものではなく、何もかもを VRM に詰め込んで欲しいと要望しているものではありません。「VRM のことは VRM のエリア (extension) で処理してほしい」という基本的な考え方を提案するものです。
強調しておきたいのは『そうすることが自明な場合やどうしても避けられない場合を除き』という部分で、VRM は現状としては実装上の都合で glTF フォーマットとしての妥当性が損なわれたり必要のない制限がかけられるケースが見られると感じており (#205 最近だと #227 など) どうしてもそうせざるを得ないのかどうかよく考えてからやろう、という提案をしています。
どちらに書こうか迷ったのですが #217 非常に興味深いです。 こちらで議論する方がまとめて見られるのでこちらに書きます。 雑感です。
自動reductionが困難になるようなglTFの仕様をVRMとして制限する
- e.g. UV wrap mode REPEATやMIRRORED_REPEATの存在はテクスチャのアトラス化を妨げます
- e.g. シェーダーの複雑性 ステンシルやculling modeの混在によってマテリアル統合が困難になります
このようなケースでは『このパラメータが入ってると自動削減がうまくいかないよ』というようなガイドラインとしてモデル作成者に周知するといった対処ではダメでしょうか？VRM はこういったケースで積極的に禁止したり制限をかける傾向にあるイメージがあります。しかし例えば海外のサービスとの連携を考えた場合（最近だと ReadyPlayerMe が VRChat との連携を始めました）glTF から VRM への変換は簡単にかけられると思うのですがテクスチャの制限などは難しい気がします。このあたりはどのようなユースケースを考えるかで方向性は変わってくるとは思いますが、私は VRM はより汎用的な glTF 形式を保っていた方がよりたくさんの人に使われると思っています。