VRMファイルを読み込んだ際にどの程度まで再現されるべきか？

[FujiSunflower]

概要

「VRMファイルを読み込んだ際にどの程度まで再現されるべきか？」

課題

VRMファイルを読み込めるアプリやローダーが増えてきたのでこの疑問を感じました。 例えば以前議論となったSpringBone.centerの項目がnullの場合に、移動速度が速いことを理由にアプリ側で読み込んだVRMデータのルートオブジェクトにCenterを設定してしまうのは妥当な行為といえるのか・MToonなどのマテリアル以外を設定するのは妥当な行為といえるのか・スペック不足を理由にVRM 1系のConstraintを無視するのは妥当な行為といえるのか、そういう再現性に関する疑問となります。 これは、現在ではUniVRMがVRMのローダーの大多数ですがUnityGLTFなどでの読み込みも行われるようになった際にどうなるだろう？という疑問でもあります。

個人的な意見

VRMファイルに内包している一部の値を活用してアプリを作成することは、VRMが最低限のデータをまとめた人型3Dキャラクター規格であるという視点としては妥当な行為と言えそうと個人的には思っています。内包している値は推奨値という考え方です。

この場合、再現しなくても仕方がない項目があるという点をアバター作者側でも理解しないといけないとも思えます。 一方で、アバター作成の際の基準となる標準的な再現環境の提供も必要なのかなと思います。

関連する課題

個人的な意見としては推奨値でも良いのですが、VRM規格の目指すものは下記の通りですのでUniVRMなどの書き出し側・読み込み側で対応すべきという考え方もあるとは思います。

「人型のキャラクターやアバター」において 細かいモデルデータの差違を吸収・統一し アプリケーション側の取り扱いを簡単にする 「VRM」は、このような特徴のある「プラットフォーム非依存の3Dアバターファイルフォーマット」を提案する ものです。

[mendosu]

アバター制作者は自身のアバターの振る舞いに関して非常に神経質になりがちです、そしてそれはクリエイターにとっては重要なことでもあります。

[sierra-tan-sama]

現にVtuber向け案件で多くVRMは採用されています。

この場合、発注・検収側と製作側間の共通認識として、どのような環境で、どのような項目をチェックするのかを本来しっかり申し合わせる必要があります。

アプリケーションによって、挙動が異なることを知らずに、ちぐはぐな環境のままでは、仕様があいまい/検収がなかなか得られない、といったケースになりかねないのです。

できるだけ同じであってほしいですが、実際にそうもいかないこともあると思います。 せめて、アプリごとに、簡素化していることや独自実装になっていることなどある場合は明示するとかの配慮がほしいです。

[FujiSunflower]

心情を補足しておくと、VRM対応アプリ固有の問題をVRM規格及びUniVRMの問題と切り分けたいというのがあります。 例え話として、SpringBoneのCenter設定をしておけば時速60kmの乗り物での揺れ物の見栄えは恐らく損なわれませんが時速1000kmの乗り物となると怪しい気もします。 そういうVRM対応アプリ固有の問題というのが恐らく存在して、この際はVRMデータ側に問題があるのではなくアプリ側に改善すべき点があるかなと思っております。

[s-iwaki-d]

VRM 1.0の規格上は、 https://github.com/vrm-c/vrm-specification/blob/master/specification/VRMC_vrm-1.0/README.ja.md

VRMC_vrm拡張は他の記載された拡張と併用して使用することを想定している、という規定になります。ですので、たとえば冒頭の例にあるconstraint (VRMC_node_constraint) 拡張は併用されることを想定しております、というのが正しい答えかなと思います。MUST項目ではありませんが、可能な限り対応していただきたいというところです。