本投稿はMecanim Humanoidの背後にある技術について説明する。動作の仕組み、長所と短所、どうして今のような選択がおこなわれたのか、さらにベストの状態を得るためのいくつかのヒントについてお話しよう。Mecanimに関する一般的な設定と手順については、Mecanim Animation Systemを参照してほしい。

HumanoidRig_pngHumanoidリグとマッスルスペース

Mecanim Humanoidリグおよびマッスルスペースは、人型のボディやアニメーションを表現するために使われる、標準的なスケルトンノード階層とジオメトリ変形を実現する代替ソリューションだ。

Humanoidリグとは、スケルトンノード階層のトップにおけるデスクリプションであり、人型ボーンのセットを定義すると同時に、各々のボーンに対応するマッスルリファレンスを作成する。マッスルリファレンスとは、本質的には各軸ごとに一定の範囲と符号を持つ事前および事後の回転のことだ。

arm_stretch_in-PNGあるマッスルは、[-1,1] にノーマライズされた値であり、ひとつのボーンを [min,max] の範囲内で1軸に対して駆動する。マッスルのノーマライズ値が [-1,1] の範囲をオーバーシュートして、さらに下回ったり、上回ることもできることに注意しよう。その範囲で制限しているわけではなく、あるマッスルに対して通常のモーションスパンを定義しているだけだ。特定のHumanoidリグは、そのモーションスパンを増やしたり、逆に減らしたりすることで、マッスルリファレンスの範囲を増やしたり、逆に減らしたりすることが可能だ。

マッスルスペースとは、Humanoidリグのすべてのマッスルのノーマライズ値のセットのことだ。それは正規化された人型ポーズである。あるボーンの軸に対し範囲がゼロ(すなわち、min = max)ということは、そのボーンに対応するマッスルがないことを意味している。

例えば、「肘」にはY軸を駆動するマッスルがない。できるのは内および外側に(Z軸沿いに)ストレッチすることと、内および外側に(X軸沿いに)ロールすることだけだ。最終的には、多くても47個程度のマッスル値によって構成されるマッスルスペースが、人型ボディのポーズを完全に記述できるのだ。

arm_stretch_out_png

マッスルスペースが美しいのは、それがオリジナルはもとよりいかなるスケルトンリグからも切り離されて、完璧に抽象化されているということだ。だから、どんなHumanoidリグに対してもダイレクトに適用することができるし、常に真実味のあるポーズを作成できる。もうひとつ美しい点として、マッスルスペースが上手に補間をしてくれることがあげられる。通常のスケルトンポーズと比較して、マッスルスペースはどんな時でも、アニメーションのキーフレーム間を自然に補間してくれることだろう。ステートマシンのトランジション中であったり、ブレンドツリーのミックス中であっても、もちろん機能する。

しかもクォータニオンやオイラー角と違って、マッスルスペースは線形補間が適用できるスカラーベクトルとして計算することができる。

人の身体と人のモーションの近似について

人型キャラクター向けに新規に作成されたスケルトンリグや、キャプチャされたアニメーションは、人のボディや人のモーションの近似となる。たとえどんなに多くのボーンがあったとしても、またどんなによいモーションキャプチャハードウェアを用意したとしても、最終的に出力されるものは本物の近似となる。

リガー、ゲーム会社、学校やソフトウェア企業の各々が、人のボディとモーションを最もよく表現できる方式とか、制作ニーズに最も適している方式といって、それぞれ独自の方法を提案してくるものだ。

Mecanim Humanoidリグおよびマッスルスペースを仕上げるにあたり、いくつかの困難な選択に直面した。私達は、高速ランタイムとアニメーションのクオリティやオープン性と、標準的な定義との間で、なんらかの妥協点を見いださねばならなかった。

スパインボーン(脊椎ボーン)が2本である理由

脊椎これは実に難しい問題だ。何故3本ではなく、2本なのか?好みの数のスパインボーンではダメなのか?いったん最新の研究を忘れてみよう。これは生物医学向けの研究ではないのだから。(もしこの分野で必要とされるレベルの精度が絶対的に必要な場合には、いつでもGenericリグが使えることは、念頭においておこう)​​。1本のスパインボーンでは足りないのは明らかだ。

2本目のボーンを追加すると、大抵の用途には間に合うようになる。さらに第3、第4とボーンを追加していっても、最終的な人体ポーズに対してわずかな改善しかみられない。これは何故か?人間の背骨が曲がっている時の様子を見ると、胸郭に当たる背骨の部分は、ほぼ剛体となっている事に気がつくだろう。すると残るものは、脊椎の基部に位置する主となる屈曲点と、胸郭基部に位置するもうひとつの屈曲点だけになる。すなわち、2つの主となる屈曲点だけが存在しているのだ。極端なポーズをとっている最中の曲芸師を見てみれば、このことがよくわかる。これらすべてを考慮することで、私達はヒューマノイドリグが2本のスパインボーンを持つように取り決めた。

ネックボーンが1本の理由

こちらは、スパインよりも簡単だ。ゲーム用スケルトンリグの多くが、ネックボーンを持っておらず、ヘッドボーンだけでその必要とされる制御を行っていることに、注意してみるとよい。

回転の自由度について

大抵のスケルトンリグ(それが特にゲーム用となると、ほぼ間違いなくと言ってよい)と同様に、Mecanim Humanoidリグは回転(Rotation)アニメーションしかサポートしていない。ボーンは、その親に対する自らのローカル移動(Translation)を変えることが、許されていない。3Dパッケ​​ージの中には、関節の柔軟性をシミュレートしたり、アニメーションをスカッシュ(押しつぶす)したりストレッチ(引き延ばす)するために、ボーンにある程度の移動を引き起こすようなものもある。私達は、今、移動に関しても自由度を加えられないか研究をしている。それは、必要以上に複雑すぎないスケルトンリグに対してアニメーションの質を補正する際に、計算性能の観点から比較的安価な方法だからである。それはまたユーザーがリターゲット可能なスカッシュおよびストレッチ(伸縮)アニメーションを作成するのにも使われることだろう。

0_twistpng

ツイストボーンがなくてもよい理由

ツイストボーンは、腕や足が極端にねじれた状態で設定される時にスキンデフォーメーションに問題が生じないようにスケルトンリグにしばしば追加される。

ツイストボーンは、ねじりによって発生するデフォーメーションを手足の開始部から末端まで分散させる役割を持っている。

マッスルスペースでは、ねじれの量はひとつのマッスルによって表現され、そしてそれは各手足ごとの親ボーンに常に関連づけられている。例:前腕のねじれは肘に発生し、手首には発生しない。

50_twistpngHumanoidリグはツイストボーンをサポートしないが、Mecanimソルバを使うことによって、各手足の親に含まれているねじれ具合をパーセントの形で取り出し、各々の子のほうに割り当てし直すことができる。デフォルトでその値は50%だが、スキンデフォーメーションの問題を防ぐのに大いに役に立っている。

ヒューマノイドのルートおよび質量の中心(Center of mass)について

さて、ワールド空間において人の身体の位置と方向を表すのに最も適した方法はどんなものだろうか?

標準的なスケルトンリグでは、階層の最上位にあるボーン(通常は、ヒップとかペルビス(骨盤)とかだが、どう呼ばれようとその位置にあるもの)にワールド空間における位置と向きのカーブが設定されている。この方式は、ある特定のキャラについてはうまく機能するが、リターゲットとなると不適切なものとなる。それは、あるスケルトンリグから別のスケルトンリグにリターゲットすると、普通、最上位のボーンが他のスケルトンに対して相対的に異なる位置と回転を持っているからである。

backflip_pngマッスルスペースでは、ワールド空間における位置を表すために、人型形状の質量の中心を用いる。質量の中心は、人間の平均的なボディパーツの質量分布で近似される。スケール調整をおこなった後で、以下のように仮定する。「人型ポーズにおける質量の中心は、すべての人型キャラクターで同じである。」これは大胆な仮定ではあるが、実際にやってみると、アニメーションおよび人型キャラクターの幅広いセットに対して非常にうまく機能することがわかる。

確かに、立ったり、歩くアニメーションに関しては質量の中心はヒップの周辺にあるが、例えばバックフリップのような、よりダイナミックなモーションの場合はどうか?その場合、質量の中心から離れていくようにボディが移動する一方で、質量の中心はアニメーションの全体を通じて最も安定的な位置に留まっているように見えるのがわかるだろう。

ボディの方向について

マッスルスペースでワールド空間の位置を質量の中心で表したのと同様に、平均的ボディ方向をワールド空間における方向として用いる。平均的ボディ方向の上方ベクトルは、ヒップと肩の中間点より計算する。従って、前方ベクトルは、上方ベクトルと、左右ヒップおよび肩のベクトルの平均との外積となる。同様に、人型ポーズにおける平均的ボディ方向は、すべてのHumanoidリグについて同じであると仮定する。質量の中心の時と同様に、歩いたり、走ったりする時は、身体下部および身体上部の方向が自然に補償されるので、平均的ボディ方向は比較的安定的に参照できる。

ルートモーションについて

ルートモーションについては後に詳しく説明するが、ひとまず入門編としては、質量の中心と平均的ボディ方向の射影がルートモーションを自動作成するのに使われているということだ。質量の中心や平均ボディ方向が人型アニメーションが安定的特性として得られることが、安定的なルートモーションにつながり、それらを使うことでナビゲーションやモーション予測に用いることができる。

スケールについて

人型ポーズを完全にノーマライズすることに関して、マッスルスペースにおいていまだ解決していないことがある。それが全体的なサイズの問題だ。重ねて言うが、私達は人型モデルのサイズを記述する良い方法を探している。各リグ間での首尾一貫性という観点から言って、それはヘッドボーンの位置のような特定のポイントに依存するものではダメだ。Tスタンス状態での人型キャラクターの質的高さの中心が、それがもつスケールとしてダイレクトに使用されている。最終的な正規化された人型ポーズを生成するためには、マッスルスペースの質量の中心の位置をこのスケールで除算する。言い換えれば、マッスルスペースは、Tスタンス時に質的高さの中心が1の人型形状になるように正規化されているということだ。マッスルスペース内のすべての位置は、正規化されたメートル単位になっていると言ってもよい。

オリジナルの手と足の位置について

あるHumanoidリグに、あるマッスルスペースを適用する場合、Humanoidリグ同士のプロポーションの違いのために、元のアニメーションとは異なる位置や回転に手足が来てしまうことがある。結果として足が滑ったり、手が正しい位置まで届かなくなったりする。マッスルスペースに、手足の位置や向きを元のまま保持するためのオプションがあるのは、このためだ。手足の位置と方向は、マッスルスペースでは人型ルート(質量の中心、平均的身体方向、人型スケール)に対して正規化される。これら手足の元々の位置と方向は、IKパスを用いることで、ワールド空間における本来の位置にマッチするように、リターゲットされたスケルトンポーズを調整するために使われる。

IKソルバについて

ikdiff_png手足のIKソルバが主に到達地点としているのは、マッスルスペースのオプションにある、オリジナルの手足の位置と方向である。これはMecanimのコントローラーステートにおいて、「Foot IK」トグルが有効になっている時に、足の制御システムがおこなっていることだ。

これらの場合、リターゲットされたスケルトンポーズが、オリジナルのIKゴールからひどく離れていることはまずない。調整すべきIKエラーが小さいのは、それがHumanoidリグのプロポーションの違いより引き起こされたものだからだ。IKソルバがリターゲットされたスケルトンをほんのわずか調整して、オリジナルの位置および方向にマッチするようにファイナルポーズを作り出すことで対応できる。

IKはリターゲットされたスケルトンポーズを微調整しているだけだから、膝や肘のポッピングのようなアニメーションでの不具合を引き起こすこともまずない。その場合でも腕や脚が最大伸展に近づいた時にポッピングを防ぐ、スカッシュおよびストレッチソルバがIKソルバには含まれている。デフォルトで許可されているスカッシュおよびストレッチの総量は、腕または脚の全長の5%以内に制限されている。肘や膝のポッピング現象は、腕や脚部分の5%もしくはそれ以下のストレッチ現象よりも、はるかに目立つ(しかも醜い)。スカッシュおよびストレッチによるソルバは、0%に設定することでオフにもできるのに、注意してほしい。

IKリグに関しては後に詳しく説明したい。小道具の扱い方、複数のIKパスの使い方、外部環境や人型キャラクター間の相互作用などを、説明するつもりだ。

オプショナルボーンについて

Humanoidリグには任意に選択できるオプショナルなボーンがいくつかある。胸、首、左肩、右肩、左つま先、右つま先がそれだ。多くの既存のスケルトンリグは、これらのオプショナルボーンのいくつかを持っていないが、それらのボーンを入れることで、よりきっちりとしたヒューマノイドを作り上げたいと考えている。

Humanoidリグは、左目と右目にあたるオプショナルボーンを同様にサポートしている。目のボーンにはそれぞれに2つのマッスルがあり、ひとつは上下移動、もうひとつは内側および外側への移動をする。目のボーンは、同時にHumanoidリグのLookAtソルバと連携する。LookAtソルバとは、「何かを見つめる(LookAt)」調整を、背骨、胸、首、頭、そして目の各ボーンに適宜割り振ることができるソルバである。今後予定しているHumanoid IK リグの説明に、LookAtソルバの詳細について書くつもりだ。

指のシステム

最後になるが、Humanoidリグは指をサポートする。各指には0から3の間で指節(digit)を割り当てることができる。 0の指節(digit)は、単にこの指が定義されていないことを意味する。親指はストレッチとスプレッドのために2つのマッスルを持っており、人差し指以降はそれぞれストレッチ用のマッスルを1つ持つ。手にまったく指が定義されていない時は、指のソルバーのオーバーヘッドは存在しないことに注意すること。

スケルトンリグの要件について

インビットウィーンボーンについて

多くの場合、スケルトンリグは、Humanoidリグによって定義されるボーンよりも多くのボーンを持っていることだろう。インビットウィーンボーンとは、Humanoidが定義している各ボーンの中間にあるボーンのことだ。たとえば、3dsMAXのBipedリグにある3つめのスパインは、インビットウィーンボーンとして扱われることになる。それらのボーンはHumanoidリグによってサポートされてはいるが、インビットウィーンボーン自体は動かないことは心にとめておく必要がある。それらのボーンは、Humanoidリグで定義されているそれら自身の親に対し、相対的にデフォルトの位置および方向を維持することになる。

標準的な階層構造について

私達のHumanoidリグと互換性を持つためには、スケルトンリグは標準的な階層構造に従っている必要がある。スケルトンは、各Humanoidボーンの間にインビットウィーンボーンをいくつか持っていてもかまわないが、以下のようなパターンに従っている必要がある:

腰・尻 – 大腿- 下腿 – 足 – つま先

腰・尻 – 背骨 – 胸 – 首 – 頭

胸 – 肩 – 上腕 – 前腕 – 手

手 – 最も近い指節 – 中間の指節 – 最も遠い指節

Tスタンスについて

tstance_pngTスタンスは、Humanoidリグを作成において最も重要なステップだ。それに基づいて各マッスルがセットアップされるからである。リファレンスポーズとしてTスタンスが選ばれたのは、概念化するのに容易であるということと、その理想的な状態に対して様々な解釈が入る込む余地がないということがあげられる。

- Z軸方向に向かって、まっすぐに立っていること

- 頭および目がZ軸方向に向いていること

- Z軸に対して平行に、両足が接地していること

- X軸に沿って地面に対し平行に、両腕が開いていること

- X軸に沿って地面に対して平行に、両手は平らにし、かつ手のひらは下向きであること

- X軸に沿って地面に対して平行に、各指(親指を除く)はまっすぐに伸ばしていること

- 親指は、X軸とZ軸に対して半分ぐらいの角度(45度)で、かつ地面に対して平行にまっすぐに伸ばしていること

ただし「まっすぐに」と言っても、それは必ずしも、ボーンが完全に一直線に整列していることを意味している訳ではない。それは、どのようにスケルトンをスキンにアタッチするかに依存する。スキン自体はまっすぐに見えるとしても、その下のスケルトンはそうでないリグもあるかもしれない。だからこそ、最終的なスキニングキャラクターに対してTスタンスがセットされることが重要なのだ。特にモーションキャプチャデータをリターゲットするためにHumanoidリグを作成している場合には、モーションキャプチャ機材の中でアクターにTスタンスをとってもらった状態で、少なくとも数フレームはキャプチャすることを推奨する。

マッスルレンジの調整

デフォルトの状態でマッスルレンジは、人の筋肉の有効範囲を最適に表現できる値にセットされている。ほとんどの場合、その値を変更するべきではない。いくつかのかなりカートゥーン的なキャラクターの場合には、身体の内側に腕がめり込むのを防ぐレンジを小さくしてみたり、脚の動きをデフォルメするためにレンジを大きくしてみることもよいだろう。モーションキャプチャデータをリターゲットするためにHumanoidリグを作成している場合は、マッスルレンジの調整はするべきではない。作り出されるアニメーションクリップがデフォルト状態を反映しなくなるからである。

リターゲティングとアニメーションクリップについて

Mecanimリターゲティングは、2段階に分かれている。ファーストフェーズでは、通常のスケルトン変形アニメーションを正規化されたヒューマノイドアニメーションクリップ(もしくはマッスルクリップ)に変換している。このフェーズは、アニメーションファイルがインポートされる時にエディタ内で行われる。このフェーズは、内部​​的には「RetargetFrom」と呼ばれている。セカンドフェーズはプレイモード中に発生するもので、マッスルクリップが評価され、Humanoidリグのスケルトンボーンに適用される。

muscleclip_pngこのフェーズは、内部​​的には「RetargetTo」と呼ばれている。リターゲットを2つのフェーズに分けることには、2つの大きなアドバンテージがある。ひとつはソルバのスピードである。リターゲットプロセスの半分は、オフラインで処理されているので、ランタイムで処理しなければならないのは、残り半分のみとなる。もうひとつの利点は、シーンの複雑さとメモリ使用量だ。元のスケルトンよりマッスルクリップが完全に抽出されているから、リターゲットを実行するランタイムには、ソースのスケルトンは含まれている必要はない。

セカンドフェーズは、実にシンプルなものだ。一度有効なHumanoidリグにしておけば、マッスルクリップをRetargetToソルバと共にリグに割り当てるだけである。このフェーズは、ユーザーの見えないところで自動で行われる。

ファーストフェーズでは、スケルトンアニメーションをマッスルクリップへと変換しているが、これは少しトリッキーかもしれない。スケルトンアニメーションクリップは固定レートでサンプリングされる。それぞれのサンプリングにおいて、スケルトンポーズがマッスルスペースポーズへと変換され、マッスルクリップにキーが追加される。あらゆるスケルトンリグがフィットする訳ではない。スケルトンリグを作り、動かすのには様々な方法があるものだから。スケルトンリグの中には、頑健なアウトプットを生み出す一方で、情報をロスする可能性があるものもある。それでは、ロスレスの正規化されたヒューマノイドアニメーション(これこそがマッスルクリップである)を作成するために必要なことを検討してみよう。

注意:ロスレスとは、この場合、スケルトンリグからマッスルクリップにリターゲットし、かつ同じスケルトンリグに再度リターゲットし直しても、アニメーションが完全な状態で保持されていることを意味している。事実、ほぼ完全な状態といえよう。腕および脚のねじれは失われるが、ツイストソルバが計算した値に置き換えられている。このドキュメントですでに述べているように、マッスルスペースにはねじれの再分配にあたる表現がない。

  • 各ボーンのローカル位置は、Humanoidリグとアニメーションファイルで同一でなければならない。Humanoidリグを作成するのに使用されたスケルトンがアニメーションファイル内に含まれているスケルトンと違っている場合に起こりえることだ。まったく同じスケルトンを使用するように注意すること。そうでない場合には、インポート時にコンソールに警告が送信される。
  • インビットウィーンボーンにはアニメーションがあってはならない。これは、3dsMAXのスケルトンを使っている時にしばしば発生する。3dsMAXのスケルトンでは3つめのスパインボーンに移動および回転の両方のアニメーションが付いているからだ。これは「Bip001」がヒップとして使われており、かつ「Pelvis」にアニメーションが付いている場合にも発生する。そうでない場合には、インポート時にコンソールに警告が送信される。
  • インビットウィーンボーンのローカル方向は、Humanoidリグおよびアニメーションファイル中のそれと同じでなければならない、これは、Humanoidの自動設定を使用している時に発生する可能性のあるものだが、この機能がTスタンスを作るためのスキンバインドポーズに依存しているためだ。各インビットウィーンボーンに対するスキンバインドポーズの回転を、アニメーションファイル内に含まれるそれと、確実に同じものにすること。もしそうでない場合には、インポート時に警告がコンソールに送信される。
  • ヒップを除き、各ボーンに付けられた移動アニメーションはサポートされない。3dsMAXのBipedリグは、時々スパインボーンに移動アニメーションを付けていることがある。そうでない場合には、インポート時にコンソールに警告が送信される。

ここでは3dsMAXのBipedリグがトラブルが起こりやすいリグとして指摘されているが、それは多分、Bipedリグに人気があり、多くのケースにおいてそれらがMecanimで使われることをサポートせねばならなかったという事実のためと考えられる。Mecanim Humanoidリグを使って新規にアニメーションを作ろうとしているならば、最初から上記のルールに従っておくほうがよいことに注意しよう。上のいくつかのルールに従っていない既存のアニメーションを使いたい場合でも、使うこと自体は問題はない。それぐらいMecanimのリターゲットソルバは頑健で、十分使えるアウトプットを出力してくれるからである。ただその場合、ロスレス変換は保証されない。

本記事はUnity3D.comの記事「Mecanim Humanoids」を翻訳したものです。

Demos, Tutorials and Tips, Technology、robertl が投稿 (投稿日:2014 年 5 月 26 日)

※本ブログの著者 robeltl(Robert Lanciault)は、Mecanimのリードデベロッパ。