Policy Change: Avoid destructive change on source mesh/bone structures

[infosia]

※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 の問題として提起することにしました。

[TokageItLab]

破壊的変更を glTF データの本体部に持たせている理由としては、インポート時に glTF データの本体部に対しての処理を行いたくないという理由がありそうですが、だからといって破壊的変更を本体部に適用した物を標準とするのは良くないと考えます。

よく問題として挙げられる、

• 再編集が困難
• Unity 外での利用が困難

これらの原因がその破壊的変更にあるように私は考えており、現状では Unity Humanoid 専用フォーマットから脱却する事は難しいと考えております。

[s-iwaki-d]

その資料で言う「ファイルが１つで完結する」というのはオリジナルのデータをすべて保持し続ける、という意味ではありません。同資料のp30もごらんいただきたいのですが、VRMはあくまでも編集用ファイル（オリジナルの情報を保持するためのファイル）ではなく出力用ファイル（データを利用するアプリケーションにとって都合がよい形式のファイル）を想定しています。

「１ファイルで完結すべき」というのは利用者が各種アプリケーションにアバターを持ち込む際に１ファイルだけ食わせればアバターとして使えるようになるべし、という話であって、１ファイルにすべての情報を保持しすべてのアプリケーションで編集可能状態を維持するのは目標とするところではありません。その用途であればfbxでいいのではないでしょうか。

そのためたとえばPSDからJPEGにエクスポートする際に画像に破壊的変更が加わるのと同じように、VRMにエクスポートする際に構成がアプリケーションに利用しやすい形で変更が加わることは自然だと考えています。

それと「その変更の過程でクリエイターの意志を伝えることが仕切れていない」という課題は直交した概念であって、何がどう足りないのか、それは仕様に落とし込むべきかどうか、を別途検討するべきです。

[TokageItLab]

アプリケーションに利用しやすい形で変更が加わる

@s-iwaki-d 現在の破壊的変更によって Unity 以外のアプリケーションでの利用が困難であるという現状が #12 や #34 で示されていると思うのですが、これは「 Unity アプリケーションにおいて利用しやすければよい」という意図で決められたコンセプトなのでしょうか。

JPEG の破壊的変更はあくまで圧縮であり、画像としての意図は伝わるだけの情報は残っている一方で、 VRM の正規化処理は明らかに元の情報が欠落しており、 圧縮と同等のように考える事はできないと思います。

[infosia]

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

[infosia]

追記します。

この issue は VRM が fbx を目指すことを提案するものではなく、何もかもを VRM に詰め込んで欲しいと要望しているものではありません。「VRM のことは VRM のエリア (extension) で処理してほしい」という基本的な考え方を提案するものです。

「 Unity アプリケーションにおいて利用しやすければよい」という意図で決められたコンセプトなのでしょうか

（追記）※以下は議論が散漫になりそうなので消させてください。

別トピックになるかもしれませんがここも気になっています。現状の 0.0 バージョンで Unity での利用のみが考慮された仕様になっているのは仕方ないことかと思いますが、VRM コンソーシアムがスタートして（詳しくは存じませんが）２年近く、 #34 が投稿されてから１年以上経った状態で、（追記：技術的に非常に難しいことを要望しているわけではないのにも関わらず、）まだスキーマも決まっていない 1.0 仕様でこの問題が特に理由を示されず対応なしとされるということは、Unity 以外のゲームエンジンでの利用についてあと何年必要なんだろうと考えてしまいます。

[s-iwaki-d]

まず、オリジナルデータを「破壊」するかどうか、というのは規格の話ではなく実装の話かと思います。 規格としては現在のところ、ボーンに回転を入れない、やTポーズである、などといった制約として定義されています。 ここで「破壊」とされているのは、その規格上の制約にそぐわないデータを制約にあわせるように変換しようとするExporter実装上の手順のことを指していると理解しています。 もともと規格に沿った形でモデルデータが定義されていればそのまま出力すればよいわけで、それは元のデータを破壊することにはなりません。

これに対して ・Exporterが本来の規格上の制約以上にデータをいじってしまう ・定義された規格上の制約が必要以上に厳しくクリエイターの意思が反映できない というような議論であればわかりますし議論されればいいと思うのですが、 本issueは ・VRMは「拡張」のみを取り扱うべきであってglTFに対しての「制約」は許されない という提案であると解釈しました。それはさすがに飛躍が過ぎるのではないでしょうか。

[TokageItLab]

定義された規格上の制約が必要以上に厳しくクリエイターの意思が反映できない

ローカル方向を全て Quat(0,0,0,1) にするというのはこちらに該当していると考えます。こちらは定義の話でもあるので引き続き #34 でも議論を続けます。

メッシュの破壊に関しては詳細は存じ上げませんが、何かしらの要員でポリゴン数が入出力時に変化するという話を耳にした事があります。（Nゴンの除去等？）何かしらの処理が入るのであればその旨を記述すべきであると考えます。

[infosia]

もともと規格に沿った形でモデルデータが定義されていればそのまま出力すればよいわけで ・VRMは「拡張」のみを取り扱うべきであってglTFに対しての「制約」は許されない という提案であると解釈しました。それはさすがに飛躍が過ぎるのではないでしょうか。

許されないというより『そうすることが自明な場合やどうしても避けられない場合を除き』という提案です。VRM の理想・取り組みは確かに野心的だとは思いますが、現状はどうでしょうか。VRM に対応したエクスポータがいくつあるでしょうか？assimp や cgltf などの著名なインポータが VRM に対応しているでしょうか？Unity ゲームエンジン以外での実績は？VRM の仕様が日本以外でどのように受け止められているでしょうか？この辺は「私はそうは思わない」という議論になればもうそれまでですが「こうあるべきだ」という理想は色々あるだろうとは思いますが Unity 以外でのゲームエンジンでの利用、UniVRM 以外でのインポータ/エクスポータへの対応を考えると、VRM を glTF の extension の一つとしてとらえた方が広く受け入れられると考えているので、上記の提案をしています。

[xanxys]

編集容易なオリジナルデータを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としては、実行時に表現されるアバターのリッチさを増やさない(=編集容易性のための)仕様肥大化は歓迎しないという意見を表明します。

[TokageItLab]

少し勘違いされておられるかもしれませんが、こちらはモジュールを追加するかどうかの議論ではなく、タイトル通り、元のメッシュやボーンに対しての変更を破壊的に行っている事に対する問題提起です。

簡単に言えばボーンやメッシュに対する変更をエクスポート時に行う必要があるのかという問題になります。例えばメッシュ割りを変更するのであればその差分のデータ、ボーンの方向を変更するのであれば変換行列を VRM 拡張部分に記録し、元の glTF に対しての破壊的変更を減らすという実装は可能ではないでしょうか。

個人的には現在の破壊的変更により一般的な glTF モデルとして扱う事が困難になっているのが問題だと考えているので、一般的な glTF モデルとして扱う事ができるような定義が実現できていれば問題ないとは考えていますが、現状そうではないので議論を行っています。ミニマルであるべきであるというコンセプトには異存ありませんが、汎用 glTF としてはどうでもよいという意見には賛同できません。 glTF としての汎用性を失った結果プラットフォームの寡占化を招く事になりますし、それは VRM 1.0 のプラットフォームを超えた汎用フォーマットというコンセプトに反するのではないでしょうか。

[infosia]

みなさんありがとうございます この issue もう閉じてしまおうかと考えていましたが盛り上がってよかったです。 私の書き方が悪かったと思うのですが誤解されやすいようなので再度書いておきます。

この issue は VRM が fbx を目指すことを提案するものではなく、何もかもを VRM に詰め込んで欲しいと要望しているものではありません。「VRM のことは VRM のエリア (extension) で処理してほしい」という基本的な考え方を提案するものです。

強調しておきたいのは『そうすることが自明な場合やどうしても避けられない場合を除き』という部分で、VRM は現状としては実装上の都合で glTF フォーマットとしての妥当性が損なわれたり必要のない制限がかけられるケースが見られると感じており (#205 最近だと #227 など) どうしてもそうせざるを得ないのかどうかよく考えてからやろう、という提案をしています。 　

[infosia]

どちらに書こうか迷ったのですが #217 非常に興味深いです。 こちらで議論する方がまとめて見られるのでこちらに書きます。 雑感です。

自動reductionが困難になるようなglTFの仕様をVRMとして制限する

• e.g. UV wrap mode REPEATやMIRRORED_REPEATの存在はテクスチャのアトラス化を妨げます
• e.g. シェーダーの複雑性 ステンシルやculling modeの混在によってマテリアル統合が困難になります

このようなケースでは『このパラメータが入ってると自動削減がうまくいかないよ』というようなガイドラインとしてモデル作成者に周知するといった対処ではダメでしょうか？VRM はこういったケースで積極的に禁止したり制限をかける傾向にあるイメージがあります。しかし例えば海外のサービスとの連携を考えた場合（最近だと ReadyPlayerMe が VRChat との連携を始めました）glTF から VRM への変換は簡単にかけられると思うのですがテクスチャの制限などは難しい気がします。このあたりはどのようなユースケースを考えるかで方向性は変わってくるとは思いますが、私は VRM はより汎用的な glTF 形式を保っていた方がよりたくさんの人に使われると思っています。

[FujiSunflower]

34 と同様のissueだと思うのでCloseで良いと感じます。

[FujiSunflower]

すごく今更の発言になってしまうのですが、当時は正規化に違和感が多かったもののゲーム素材としての利用を考えていくと常識的に回転0スケール1の状態が正しいと思います。 というのもユーザー側であえてスケール値や回転値を仕込むのを想定しているとも言えてしまうからです。 VRMを再編集したいという要望も勿論あるのですが、PSDデータではなくPNGデータを目指しているということなら納得できます。

そして当時何故違和感が多かったのかを考えてみたところ、VRM 0系を仮出力して再度インポートして出力する編集方法に違和感があったのかなと思いました。 VRM 1系のようにUnityエディタ上でボタンを押すと仮設定が行われて出力出来る現在の編集方法だとあまり違和感が無いかなと思います。 そしてVRM 1系の出力の際に正規化言い換えるなら現在のシーンのワールド空間の状態が書き出されることになったとしても違和感が無いと思います。

VRMを再編集したいという要望にも答えておくと、うちのところの個人作成アプリにはなってしまうのですがVRM 0系いわゆる正規化がある状態でも出来ました。 そしてVRChat向けアバターで行われている再編集というのは、Unityエディタ上でアバターの階層に服の階層を入れ込んでしまうというやり方です。 この行為を行う際にVRM 0系を仮出力して再度インポートして出力する編集方法だとたびたび問題が起こりました。そのためVRM 0系は再編集出来ないと思われていたのかなと思います。

[TokageItLab]

ゲーム素材としての利用を考えていくと常識的に回転0スケール1の状態が正しいと思います。

正しいか正しくないかはアプリケーションによって決定されるもので、回転 0 スケール 1 のような、いわゆる「データの破棄」であればアプリケーション側のインポート時に行なえば済むという話であり、回転を削除するのが常に正しい、とはならないと思います。

問題の本質としてはユーザー側が回転を任意に決定できるようになったが、その基準が未だに VRM 1 にない（モデルによって関節の軸が異なる）ことではないでしょうか？

VRMを再編集したいという要望も勿論あるのですが、PSDデータではなくPNGデータを目指しているということなら納得できます。

また、これは的確な例えではないように前々から思っております。回転の破棄はどちらかというと SVG を PNG にラスタライズしてしまっているようなもので、再編集のためではなく、むしろそれを正しく描画（アニメーション）するための情報が欠落しているという例えの方が正しいでしょう。

[FujiSunflower]

実は個人的には同じ想定だったのです。差分情報のようなものを保持してインポート側で必要に応じて正規化をする。 ですが、現状は正規化自体を一切しない状態となっていますので想定と異なっています。

そして恐らく同様に感じているglTFデータとして読み込んだ際の違和感なのですが、回転0スケール1のglTF自体はよくよく考えると存在します。

そして問題視しているアニメーションに関してなのですが、初期の回転0スケール1が保証されていないと状態で例えば1倍から10倍にするスケールアニメーションなどをさせてみると、初期スケールが50だったりした場合に想定したアニメーションになりません。

[TokageItLab]

そして恐らく同様に感じているglTFデータとして読み込んだ際の違和感なのですが、回転0スケール1のglTF自体はよくよく考えると存在します。

回転 0 スケール 1 が glTF として正しくない訳ではなく単純にモデラー側の意図した描画、アニメーションが行なえない可能性があるのが問題になります。

そして問題視しているアニメーションに関してなのですが、初期の回転0スケール1が保証されていないと状態で例えば1倍から10倍にするスケールアニメーションなどをさせてみると、初期スケールが50だったりした場合に想定したアニメーションになりません。

はい、そのような問題があるため、VRM 1 でもスケールに関しては 1 で固定されている筈です。

[FujiSunflower]

スケールは正のユニフォームスケールですので1以外もあり得るのが現状です。 そして、VRMとして書き出した時点を完成状態と考えるとモデラー側の意図した描画・アニメーションになりますよね？

[saturday06]

スケール1固定なのはVRMAでした https://github.com/vrm-c/vrm-specification/blob/master/specification/VRMC_vrm_animation-1.0/README.ja.md?plain=1#L137

[TokageItLab]

VRMとして書き出した時点を完成状態と考えるとモデラー側の意図した描画・アニメーションになりますよね？

これについては VRM はローカル軸の方向を破棄すべきでない で言及したように、特定のジョイントを回転させたいとなった時に、回転を破棄してしまっている場合にモデラーの意図しない関節の変形が発生する事が問題です。「ジョイントを回転させたい」というのは編集だけでなく IK やアニメーションにも適用されることであり、回転の破棄は「編集ができない」という制限を超えて「ボーンアニメーションを思った通りに適用できない」というモデラーやユーザーが望んでいないであろう制限をもたらします。

リターゲットにおいてはそのアルゴリズムに依りますが、例えば「指の関節はXで曲げる」というルールを持った VRM 間で「相対アニメーションを共有する場合」（Blender においては単純なアニメーションターゲットの置換は相対アニメーションになります）、回転を破棄してしまった場合はどうやっても綺麗にリターゲットできなくなり、モデルが骨折してしまいます。

スケール1固定なのはVRMAでした

スケールのアニメーションはせん断による問題も発生し、せん断の扱いを VRM として定義してしまうとレンダラーのようなエンジン側のかなり深い所で修正が必要になるため、スケールをとりあえず 1 にしておくのは許容範囲かなと思っております。

対してモデル間の回転の差異に関しては単純にインポート時やアニメーション時、または編集時の計算によりアプリケーション内部で VRM ファイルそのもののデータを書き変えずとも非破壊的に解決できる問題であるため、フォーマットとしては保持されるべきでしょう。

[saturday06]

問題の本質としてはユーザー側が回転を任意に決定できるようになったが、その基準が未だに VRM 1 にない（モデルによって関節の軸が異なる）ことではないでしょうか？

個人的にBlenderのアドオン書いている身としては、こちらの基準があるとすごく嬉しいというのが正直あります。Blenderはボーンの進行方向がY固定なのと、最近Blenderに追加された「ボーンの見た目をカスタマイズできる機能」が非常に不評のため、インポート・エクスポート時に軸変換を行っているのですが、その軸変換は自前のヒューリスティックな推定ロジックになってしまっていてとても邪悪になってしまっているという事情があります。

困る例としては「特定のアイトラッキングソフトウェアの事情で目の回転をゼロにしたい」という要望があるのですが、自前推定するとどうしても目の方向は進行方向を向いてしまうので、例えばVRMを再編集する場合に、もともと回転ゼロであった目の軸が勝手に変わるという現象が発生し、そのような要望に応えられなくなってしまっている。

[TokageItLab]

個人的にBlenderのアドオン書いている身としては、こちらの基準があるとすごく嬉しいというのが正直あります。Blenderはボーンの進行方向がY固定なのと、最近Blenderに追加された「ボーンの見た目をカスタマイズできる機能」が非常に不評のため、インポート・エクスポート時に軸変換を行っているのですが、その軸変換は自前のヒューリスティックな推定ロジックになってしまっていてとても邪悪になってしまっているという事情があります。

オフトピックになるかもしれませんが、これは恐らく本当に見た目だけが主な問題なので、八面体をHEAD間に描画するようにする等の見た目の改善をして Blender 4 の glTF インポートに準拠するように、推定をデフォルトでオフにするのが良いようには思います...（Blender の Gizmo 作るのがそれほど容易ではないのは分かりますが）

その上で VRM 0 に関しては軸の変換を行なうべきである筈なので、そこに基準が欲しいというのは完全に理にかなっています。

[FujiSunflower]

過去の議論と同じ流れになりそうですが一旦発言しておくと、UniVRMではメカニム機構であまり気にせずアニメーションリターゲットが行われます。そのほかのインポーターを考えた場合インポートした際に方向推定を行う方法があります。

[saturday06]

(すみません私の話はオフトピでした。機会があればDiscordとかXとか別の場所で議論ができたらと思います)

[FujiSunflower]

初歩的な質問になってしまうのですが、ローカル軸の話題に絡んでくるコンストレイトが何を目的として用意されたのかが分かっておりません。

[saturday06]

(すみません、コンストレイントも関係あるかなと思ってコメントをしたのですが、こちらもまたオフトピになるかと思ってすぐに削除してしまったため、FujiSunflowerさんのコメントの議論がかみ合わなくなってしまいました。失礼しました。コンストレイントの話も機会があれば別の場所でできればと思います)

[FujiSunflower]

オフトピでもないので書いておくと、ローカル軸を前提としないコンストレイントの設定も出来ますよね。

[TokageItLab]

過去の議論と同じ流れになりそうですが一旦発言しておくと、UniVRMではメカニム機構であまり気にせずアニメーションリターゲットが行われます。そのほかのインポーターを考えた場合インポートした際に方向推定を行う方法があります。

はい、なので回転についてはインポーター側が担保すべきという事になります。VRM が UniVRM 専用のメカニムを使うフォーマットである、という前提なのであれば回転が 0 スケールが 1 のような定義も可能だったかもしれませんが、VRM 1 が Unity 依存を断ち切った汎用フォーマットであることを謳う以上は、他のプラットフォーム上で利用できる形でなければなりません。

回転が 0 スケールが 1 の場合、「そのモデルで作成したアニメーションを再生する」だけなら見た目は担保されますが、「他のモデルのアニメーションを流しこむ」「IK のために回転軸を指定する」などといった場合に、それを扱う方法が骨折を伴う破壊的なリターゲットしかありません。

メカニムを利用する場合であっても VRM に対して破壊的なリターゲットを行なうことでこれを達成している筈ですが、他のプラットフォームにもこれを強制する理由は汎用フォーマットにはないと思います。Unity 上であっても、IK の軸指定に関しては回転を破棄しない方が基本的にはよい結果になります。

初歩的な質問になってしまうのですが、ローカル軸の話題に絡んでくるコンストレイトが何を目的として用意されたのかが分かっておりません。

主に捻りボーンについて解決するものとなります。例えば Blender 上などで試してもらうと分かるかと思いますが、ジョイントをロールさせた時にスキンが痩せてしまいます。

コンストレイントがなくとも、Unity のメカニムの環境であればジョイントをロールさせた時にスキンが痩せてしまう事を防ぐための補正がかかったりするのですが、これも汎用フォーマットを謳う上では他のプラットフォームに持ちこむことができないものなため、各プラットフォームで比較的容易に扱えるコンストレイントが必要になります。

モデラーからすると、スキンの変形時の見た目を担保するデータ、ということになります。

オフトピでもないので書いておくと、ローカル軸を前提としないコンストレイントの設定も出来ますよね。

過去にローカル軸を別のデータとして保持するみたいな話がありましたが、glTF はデフォルトでローカル回転のデータを持つため、「元のローカル回転のデータ」と「破棄された回転のデータ」というように回転についてのデータが無駄に２倍になってしまいます。また、最初に延べたように回転についてはインポータが担保すべきなため、そのような回りくどい実装は Evil であるというように結論づけられると思います。

[FujiSunflower]

モデラーの意図しない関節の変形が発生する事 https://github.com/vrm-c/vrm-specification/issues/214#issuecomment-1973547098

同じ文になりますが、VRMとして書き出した時点を完成状態と考えるとモデラー側の意図した描画・アニメーションになりますよね？

[TokageItLab]

同じ文になりますが、VRMとして書き出した時点を完成状態と考えるとモデラー側の意図した描画・アニメーションになりますよね？

そもそも前提が間違っており、モデラー側の意図した書き出しができていない、と言えるのではないでしょうか？

モデラーとしての完成状態というのはアプリケーション上での完成状態であり、VRM として書き出した後の見た目（VRM 0 だと軸が変わってしまっている）ではない筈です。

[FujiSunflower]

なるほど回転0スケール1の状態で書き出したVRMを読み込んだアプリケーションでのVRMの見た目に関しての発言なのですね。 作業に関われておらず申し訳ないところですが、これはUniVRMやVRM Add-on for BlenderやVRM addon for Godot Engineのインポーター側の擦り合わせに関する問題かなと思います。

[FujiSunflower]

ローカル軸を前提としないコンストレイントの設定

コンストレイント自体を実装したとしても、モデラーによるワールド回転を前提としたセットアップも出来ますよね。

[TokageItLab]

コンストレイント自体を実装したとしても、モデラーによるワールド回転を前提としたセットアップも出来ますよね。

何の機能について話されているか分からないのですが、VRM フォーマット内の話ですか？　現時点で VRM 1/VRMA が担保すべきとなっているのは VRM モデルのボーンアニメーションやブレンドシェイプについてのようなものであって、その他のアニメーションについては定義されていない筈です。

ローカル軸を前提としないコンストレイントの設定

オフトピでもないので書いておくと、ローカル軸を前提としないコンストレイントの設定も出来ますよね。

上記については、https://github.com/vrm-c/vrm-specification/issues/214#issuecomment-1973618506 にコメントした通りになるはずです。

過去にローカル軸を別のデータとして保持するみたいな話がありましたが、glTF はデフォルトでローカル回転のデータを持つため、「元のローカル回転のデータ」と「破棄された回転のデータ」というように回転についてのデータが無駄に２倍になってしまいます。また、最初に延べたように回転についてはインポータが担保すべきなため、そのような回りくどい実装は Evil であるというように結論づけられると思います。

もしアプリケーション側の回転を 0 にして、かつローカル回転のデータが別に必要があるとしても、インポータが回転を破棄する時に元の回転を別に保持すべきであり、glTF のローカル回転のデータを VRM フォーマットの時点で破棄する必要はありません。

[FujiSunflower]

捻りボーンの解消を目的として、ローカル軸を前提としたコンストレイントの実装は必須ではないはずです。 ワールド軸を使用するコンストレイントでも出来るはずです。 そして、仮にローカル軸を前提としたコンストレイントでも捻りボーンの解消は完全には出来ません。

[TokageItLab]

ワールド軸を使用するコンストレイントでも出来るはずです。

いいえ、ローカル回転のコピーはできません

移動・回転方向の指定ができない

そして、仮にローカル軸を前提としたコンストレイントでも捻りボーンの解消は完全には出来ません。

完全に解消はできなくとも、それらの実装が全く無いよりは遥かにモデラーの意図した変形を再現可能になります。０か１かで全てを判断するのであれば、そもそもほとんどのプログラムにはバグがあり不完全であり、世の中に出るべきではないと言えるしょう。

またコンストレイントはロボットアームや二重関節のような用途にも利用されます。VRM はアバターとしての表現を包括する概念によるフォーマットであるため、それらにとってこれは意味のあるものになります。

[FujiSunflower]

こちらはワールド回転コピーのコンストレイントです。こちらで出来ますよね。

[FujiSunflower]

話が散らかってきたので少しまとめると、ローカル軸保持を必要とする理由は大きく2点かなと思えます。

• UniVRM以外のインポーターでのアニメーションリマッピング
• コンストレイントの実装のため

[TokageItLab]

こちらはワールド回転コピーのコンストレイントです。こちらで出来ますよね。

コンストレイントでワールドスペースを利用するために本来のローカル軸を変更してしまうのはモデラーの意図に反するものになる筈です。

議論の意図があまりよく分からなくなってきたのでお聞きしますが、

• どの開発環境で
• どのようなアプリケーションを開発していて
• 軸が揃っていないためにどのような問題に実際に遭遇した

というのをまとめて issue に上げるなどすべきかと思われます。その中で実際の実装について具体的な回答が可能になるでしょう。殆どのケースにおいては回転を計算してスキンを修正するなどの実装により、VRM フォーマットそのものの定義を変えることなく解決できる筈です。

個人的な信条になりますが、実際にそれなりの実装で解決できるケースにおいては、開発者が楽をするために VRM ユーザーやモデラー側に表現上の制限がかかってはいけないと考えています。

[FujiSunflower]

コンストレイントでワールドスペースを利用するために本来のローカル軸を変更してしまうのではなく、ワールドスペースを利用したコンストレイントに合わせてモデラー側がセットアップするのは可能ですよね。 あえて逆のことを言いますが、ローカルスペースを利用したコンストレイントに合わせてモデラーがセットアップするのもモデラー側に表現上の制限となります。

[TokageItLab]

あえて逆のことを言いますが、ローカルスペースを利用したコンストレイントに合わせてモデラーがセットアップするのもモデラー側に表現上の制限となります。

これはもし必要であれば VRMConstraint にワールドスペースを利用できるように要望を送るべきであって、ローカル軸を破棄しろという問題とは全く関係がありません。

[FujiSunflower]

話が上手く伝わっていなくて恐縮ですが、ローカル軸を前提としたコンストレイントを実装しようとするのではなくワールド軸を前提としたコンストレイントの実装でも捩じりボーンの解決は出来ますよね？

[TokageItLab]

話が上手く伝わっていなくて恐縮ですが、ローカル軸を前提としたコンストレイントを実装しようとするのではなくワールド軸を前提としたコンストレイントの実装でも捩じりボーンの解決は出来ますよね？

全ての軸に対して回転をコピーするのであればローカル軸の破棄により実現可能かもしれませんが、問題は特定の軸の回転のみをコピーしたい場合で、これはローカル軸の破棄を行なっている状態であれば骨折が発生する原因となる筈です。

[FujiSunflower]

その通り、ねじりボーンの解消はすべての軸の回転コピーで出来ますよね。仮に完全に解消出来ないとしても発言の通りかなと思います。

完全に解消はできなくとも、それらの実装が全く無いよりは遥かにモデラーの意図した変形を再現可能になります。０か１かで全てを判断するのであれば、そもそもほとんどのプログラムにはバグがあり不完全であり、世の中に出るべきではないと言えるしょう。

[TokageItLab]

その通り、ねじりボーンの解消はすべての軸の回転コピーで出来ますよね。仮に完全に解消出来ないとしても発言の通りかなと思います。

コンストレイントの設定方法にもよるかと思いますが、自分の把握しているワークフローにおいては捻りボーンはロール軸の回転のみをコピーすべきであり、その他の軸はコピーせずに親子関係を持つだけになります。この時ロール軸が正しく設定されないのがローカル軸の破棄の問題になります。

VRM 0 の定義においてローカル軸がワールド軸と一致していたとしても、ジョイント同士が軸上に一直線に並ぶというのは VRM 0 の定義ではありません。

[FujiSunflower]

そのワークフローももちろん存在すると思います。そして仰る通り基本的なワークフローというものがあります。 そして現在の基本的なワークフローに合わせるとするならば、ゲーム素材にスケール値が含まれているのは最大のご法度です。

[TokageItLab]

いずれにしても VRM 1 のローカル軸情報に関してはインポーターが担保するものであり、エクスポーターは関与すべきではなく、それは開発者側でなんとでもできる事です。

とりあえず https://github.com/vrm-c/vrm-specification/issues/214#issuecomment-1973721941 の通りにする事を推奨します。

・どの開発環境で ・どのようなアプリケーションを開発していて ・軸が揃っていないためにどのような問題に実際に遭遇した

というのをまとめて issue に上げるなどすべきかと思われます。

インポート時の正規化の実装方法が分からないのであれば個別の issue の中で解説できるでしょうし、スケールだけ破棄（適用）したいのであればそれを position に変換するような計算を行なうだけです。

UniVRM にスケールを含む VRM をインポートして問題が出たというのであれば、それは UniVRM に issue を投げるべきであり、vrm-specification リポジトリで議論することではない筈です。

[FujiSunflower]

何故「いずれにしても」なのでしょうか？

[TokageItLab]

VRM 1 の間はそのような正規化の再実装のような破壊的な変更を定義側で行なう事は通常では考え難いからです。

[saturday06]

======= すみません、議論が荒くなってきました。一度ここでストップお願いしたいです ===========

[FujiSunflower]

とりあえず寝ましょうか