vrm-specification
vrm-specification copied to clipboard
vrm-c
VRM向けモーションデータの標準化
人型3Dモデルのアニメーションを、異なるモデル・アプリケーションで共有するためのファイル形式を定義できないでしょうか。
一案として、例えば以下のようなデータ構造で。
- 経過秒数
- hipsのTポーズからの相対位置(x,y,z)
- ボーンの回転(x,y,z,w)
- hips
- leftUpperLeg ︙ ︙
- Presetのモーフの値
- A
- I ︙ ︙
- 経過秒数 …… ︙ ︙
VRMファイル自体についての仕様ではありませんが、VRMを前提とした形式になると思いますので、こちらにissueを立てさせてもらいます。
ご要望ありがとうございます、やはり独立したモーションファイルがあると便利ですよね。 ただVRMはリターゲティング機構を定義しておらず、そうするとFKのアニメーション伝達になってしまうため、他のモデルにモーションを当てた時に腰が浮いたり足が滑ったりしてしまって、汎用モーションとして使うのは難しそうに感じます。 もちろんモーフ込みのモーションファイルとしては良いと思います、VRMならLookAtの情報を記録しても面白いと思います。 もしやるならば、hipsの高さを記録しておいてモデルの腰の高さとの差でスケールする等の工夫が必要かと思われます。 以前から要望はあったため仕様を検討してみます。
hips の高さの格納には大きく賛成します。しかし、 Humanoid ボーン以外へのアニメーションは許可しない感じですかね？
これについて、 root をボーンとして定義したアニメーションもといルートモーション(※1)への対応を希望します。
最近のゲームエンジンではルートモーションという機能があり、移動モーションや攻撃モーションを実装する際に、基本的に hips の上に root ボーンを追加し、その root ボーンへアニメーションをつけます。この時、体格差による歩幅を調整する為には、足の長さつまりアニメーションを作成したモデルの hips の高さと適用するモデルの hips の高さの比率を用いるとスリップを抑える事ができます。 root ボーン自体はモデルの読み込み時に原点にジョイントを追加するだけなので、アプリケーション側で容易に対応できるのですが、アニメーションファイルの方で root ボーンが許可されていない場合どうにもならなくなるので...。
異なるモデル・アプリケーション
また、 0.x 現在の VRM ではモデルのローカル方向が破棄されているので、ローカル方向が定義されていないと指が変な方向に曲がるといった事が考えられます。そちらについては #34 を参照して下さい。
※1: ルートモーションについてはこの辺りを参照... Unity にも同等の機能がありますが Mecanim(?) 準拠で分かり辛い https://docs.unrealengine.com/ja/AnimatingObjects/SkeletalMeshAnimation/RootMotion/index.html https://qiita.com/4_mio_11/items/8e5662931aaefe4e2bf9
こちらの仕様は、結局のところ盛り込まない方向なのでしょうか？
現状、ボーンアニメーションの多くは、ゲームエンジンのリターゲットで対応しています。 もし専用のモーションデータが保持できれば、ゲームエンジン縛りが無くなり、利用の幅が広がります。
非常にシンプルな提案なのですが、glTF2.0のアニメーション仕様を、VRMにそのまま継承する案はいかがですか？ 3DCGアプリでモーション付けをして、それを破棄せずに保持してくれるだけで、非常に嬉しいです。
リターゲットは、ゲームエンジンや3DCGアプリ側に責務を持たせるパターンです。
glTF 2.0 のアニメーション仕様を VRM にそのまま継承するのであれば、単純にアニメーションを付けたモデルを glTF として出力すればよいように思えるので、VRM としてアニメーションデータを定義する意義は薄いと感じますがその点は如何でしょうか。
一つ問題があるとすれば、glTF アニメーションはローカル軸破棄前のレストポーズを起点としてアニメーションを行います。また、私の記憶が間違っていなければ、glTF アニメーションには「レスト」と「ポーズ」の区別が存在せず、全て「レスト」の値をアニメーションさせるような形で記録されているという点において glTF 2.0 のアニメーション仕様そのままでは少し扱いづらいかと感じます。この点、VRM モデル自体がローカル軸を破棄する現状においては、アニメーション側もローカル軸を破棄すればさほど問題にならないので、エクスポーター側の問題となります。
なので、例えば @qhnu さんが blender を使っているのであれば、「blender の VRM addon にローカル軸を破棄した上でのアニメーション付き glTF を出力して欲しい」という要望を出すのが良いのではないでしょうか。
またその際、モーションの使い回しを考えているのであれば、human bones のリネームをするしない等のオプションがあったほうが良いかもしれません。VRM モデルの glTF ノードとしてのボーンの名前には元の名前がそのまま用いられているので、ボーン名に直接 glTF ノード名を用いるアプリ上で、異なるボーン名をもつモデルの間でアニメーションを共有するのであれば、どこかでリネームが必要になります。
@TokageItLab
blender を使っているのであれば、「blender の VRM addon にローカル軸を破棄した上でのアニメーション付き glTF を出力して欲しい」という要望を出すのが良いのではないでしょうか。
確かにエクスポーター（または利用環境側のインポーター）の役割だと思いました。 要望は取下げ致します。
なお、なぜVRMにアニメーションを持たせたかったか？という経緯だけ簡単にご説明致します。
-
@pixiv/three-vrmを使って、Web上でVRMを読み込み - glTFにアニメーションを持たせ、それを読み込んだVRMで使用
- 座標軸が合って無く、大変な動きに
- 仕様の異なる保存データで、アニメーション部分だけ共用するのは辛みがある
という流れで要望を出しました。
アニメーション側のローカル軸を破棄すると対応できる、という情報は初耳でした。 ありがとうございました。
アニメーション側のローカル軸を破棄すると対応できる
@qhnu もしくは、初めからローカル軸を破棄した状態のモデルをアニメーションさせて glTF アニメーションを書き出すことで、想定通りのアニメーションが適用できる筈ですが、そもそもローカル軸を破棄してしまうことによりモデルの関節の正しい回転方向が分からないという問題があるので、決して良い方法とは言えません。宜しければ #34 やこちらの記事も参考としてご覧下さい。 https://qiita.com/TokageItLab/items/e5880123a9f508b2769d#%E3%82%A2%E3%83%8B%E3%83%A1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%85%B1%E6%9C%89%E3%81%8C%E5%AE%B9%E6%98%93%E3%81%AB%E3%81%AA%E3%82%8B
VRM連携アプリを作ってる側としての意見です。 VRM向けモーションデータの標準化のアイディア自体は面白いとは感じます。一方で、VRM連携アプリでは必ずそのモーションデータを使用しなければならないのかが曖昧な状態に感じます。 VRM連携アプリはアバター作者の方のこだわりを尊重しながら作成するのですが、歩き用のモーションが指定されてしまった場合にVRM連携アプリ側で必ずその歩き用のモーションを使用するのか？ということです。 元々この要望はVRChatのようにアバターをゴリゴリにカスタマイズすることを想定している思います。VRChatのサービス側でVRMを読み込めるようにして、VRMをカスタマイズできる機能があれば十分な可能性があります。
VR時代の3Dキャラクター・アバター使用を想定したプラットフォーム非依存のファイル形式です。 従来の3Dモデルとしてのテクスチャやボーンといった情報に加え、視線設定など一人称で操作するアバターに必要な情報を扱えるようにし、環境により異なるスケールや座標系などを統一することで、3Dアバターが配信・ゲームなどあらゆるプラットフォームで使用されることを想定しています。 また、人が操作して人格を演じるアバターの特性を考慮して、このアバターを他人が使用しても良いか、暴力表現をしても良いか、などアバター特有の権利までもファイルに埋め込むことが可能です。 将来的には3Dモデルの権利保護の機能を兼ね備え、アイテムやアバターの着せ替え販売を実現するなど3Dモデルが流通する際の標準フォーマットを目指していきます。
「人型のキャラクターや3Dアバター」において 細かいモデルデータの差違を吸収・統一し アプリケーション側の取り扱いを簡単にする
VRMは例えばApexのようなシューターゲームでも使用出来ることを目指しているのだと思いますし、各ユーザーのアバターでシューターゲームを楽しめたらきっと楽しいと思います。 ところでシューターゲームはプレイヤー同士が戦って競うゲームですので、プレイヤー同士の公平性が求められます。 歩きモーションが床に這いつくばって動くことを想定されているアバターが居なくもないはずです。 そうなるとVRM連携アプリはどちらを優先する必要があるかで差異が生じます。VRMに保存されている情報で取り扱いの大きな差異が生じてしまったらVRM規格の価値は無いと思います。
過去にコメント書いておりますが、VRMファイルに仕込むのではなく新しくVRMAファイルが作れるという説明をVRM meetupで聞いて納得しました。 https://cluster.mu/e/b06a4df3-b181-4f38-9977-d57f3e369b99
基準について アニメーションを作成する際に、作成するためのモデルの、ボーン間の間隔、角度などは、先に定義しておくほうがベターです。
現状では、アニメーション作成時に利用するボーンは厳密な基準がありません。Ｔスタンスであることは察せられるものの、体形からくるボーンの位置などは未定義です。 例えば肩幅や腕の長さが違えば、角度情報だけでは、手を合わせるときに足りなかったり行きすぎたりします。
どのみち適用する先のVRMもバラバラではないか、というのはあるかもしれませんが、だからといってアニメーション自体がバラバラでいいわけではありません。 先ずはアニメーションの仕様がきちんとして、それに対してモデルやリターゲットの仕様がどうあわせるか、というアプローチであるべきです。
例えばVRoidのモデルでもよいのです。アニメーション作成の基準モデルを決めておいたほうが良いと思います。
