当たったらどうすんだよ

当たらなければどうということはない

物理的に正確なヤツについて

はじめに

こんにちは、物理的に不正確ななんです。
この記事はどうやらUnreal Engine 4 Advent calender 2020 その2の12番目の記事にあたるようです。

今回はぼくにしては辛口に書くのです。なぜなら時間がないのです。年末進行なのです。ラインディレクションをいくつか兼任しているのでヤバイのです。
※しかし弊社、超過業務を強制されることはないし、自主的にも気が乗らないことは一切していないので精神的にとっても楽です。
※そういう文脈でいうと、望んで忙しくしているのは自分自身なので忙しいことウェルカムではありますが、こうした知見共有の機会が若干失われがちなことはSorryと思っている次第でございます。

qiita.com

お題「物理的に正確なヤツ」とは?

わりとアレでございます。聞きなれたようであり、しつこかったり面倒くさかったりなにを言っているんだかよく分からなかったり、開発者側からはさもそれが素晴らしいことで価値あることであるようにプレゼンテーションされるのですが、実際それってどんなメリットがあるんですか?とか、なにそれおいしいの?と言われがちなヤツです。

「物理的に正確なレンダリング」もしくは「物理的に正確なライティング」です。
別名「PBR」でございます。Physically Based Renderingです。

実際のところ、PBRという言葉は知っていても実際にどういうことが行われているのか?っていうと、この記事のタイトルにもある通り「物理的に正確なレンダリングがー!」って念仏のように唱えられるばかりで、内実たるやを語れるひとは意外なほど残念なほどに少ない、というのが観測事実だったりします。

では方針。
今回はシェーダとかマイクロファセット関数の話とかは一切しません。この記事では「UE4における物理的に正確なライティング」について的を絞る所存です。ちょっとテンションがおかしいのはアドカレ公開当日に記事を書いているという焦りと、まぁ間に合うだろう大丈夫だろう本当に大丈夫かなぁ?という、余裕とは言えないようなしかして焦ってもしゃぁないやろ書いたらええやんけ的な空気感が成せるワザであります。

UE4プロジェクトでよくあるやつ

おもむろにプロジェクトを開きましょう。みんな大好きThird PersonでOKです。

f:id:kanianthi:20201212104527p:plain

☝平板!まちがい…開いた!

なにか不可思議な赤いキャラクタが見える?そうですかお疲れのようですね。眼科か心療内科の受診をお奨めします。もしくは完全食品である寿司を摂取すればいつものグレーマンさまがウホウホ歩く安心が得られるはずです。

Unreal Engine 4といえば…数多のハイエンドゲーム、メジャータイトルに採用され、近年ではゲームの枠を飛び越えて映画のプリビズだとかテレビの放送だとか建築・工業のプロダクトデザインやプレゼンテーションに利用されるなど、高品質な映像とパフォーマンスが売りです。既存の事実です。実証されています。

筆者自身、出身は出版と広告であり実写映像とCG映像分野がもともとのフィールドです。そのため現実のカメラだとか印刷については一定の知識を持ち合わせているのですが、確かにUE4レンダリングは非常に高品質であることを感じつつも、なにか微妙に釈然としない思いというのがありました。

謎の数値「Intensity 2.75lux」について

これなんだか分かりますか?
はい、そうです。UE4純正テンプレートでよく見かける数値です。

f:id:kanianthi:20201212110751p:plain

☝ハイコレ

Third Personとかでプロジェクトを作成するとDirectional Lightがこの数値に設定されています。この2.75luxという数値がどこからきているのか?というと…ちょっと調べてみたのですが分かりませんでした。

もう少し正確に話を。

2.75という数値の根拠や理由はよく分からないのですが、luxというのはきちんと規格化された単位です。

ルクスとは、国際単位系における照度の単位である。SI組立単位「ルーメン毎平方メートル」に与えられた固有の名称であり、日本の計量単位令では「1平方メートルの面が1ルーメンの光束で照らされる時の照度」と定義されている。 luxという名称は、ラテン語で光を意味する語からとられたものである。(wikipedia日本語版)

☝と、このように単位として定義されています。さらに、

docs.unrealengine.com

UE4公式ドキュメントにおいても、実に簡潔にluxとルーメン、カンデラについての解説が成されており、スタジオライティングとか映像制作の現場で使われている単位とまったく同等の定義が行わていることが分かります。

しかしながら…謎の数値「2.75lux」です。一体どこから来たのか…しかも感覚的にはこの不思議な数値で照らされたシーンの明度は適切であるかのように見受けられます。

ところが…これが大きな罠だとぼくは考えていて「なんとなくふつーにライティングされているように見える2.75lux」をベースにゲームを作ったり映像を作り始めてしまうと、現実的なライティングを定量的に行った場合、いろいろな不具合に必然的に絶対的に避けられることなく遭遇してしまうのです。

定量的に話そう

エンジニアリングにおいて「定量的に話す」ことは不可欠である、と考えています。

たとえば競技用自動車のサスペンションセッティングをする際、スプリングをもう少し硬くしようとか言う場合、ドライバーもエンジニアも「バネ定数」に基づいて会話をし、最適なセッティングを見出します。エンジンの適正空燃比率を探す際も、理論空燃比14.3:1をベースにピストンを溶かさず排気系が十分に耐えられる燃焼温度を探っていくわけです。

しかしながら、ことアート分野では「もうちょっと明るく」だとか「赤みを少し出しましょう」という具合に、甚だ感覚的かつ主観的に物事を進めようとするきらいがあります。

誤解なきように少し掘り下げると、現実のデザインの現場ではそんな「ふんわりした話」ではすみません。クライアントだったり、広告代理店の人間はまさに「もうちょっとあーしてー」などとリクエストをしてくるのですが、スタジオのライティングエンジニアはタングステンライトの光量を数値で捉えていますし、ステージ音響のSRエンジニアはどこの周波数をどれだけ上下することでリクエストにあった音質が客席に届くのかを「計算」しています。ウーレのグライコは伊達じゃないのです。

話をUE4に戻しましょう。

問題の2.75luxですが…これ現実的にあり得ない数値です。

issekinichou.wordpress.com

こちらの記事が非常に有用ですので紹介します。グレイト!

  • 100,000:晴天の昼の太陽光
  • 1,000:晴天日の入り一時間前の太陽光
  • 100:街灯下
  • 1:月明り

☝よく使うlux値を抜き出すとこんな感じ。
定量的に2.75luxを考えると「夜の街路」くらいの照度が2.75luxの物理的な値になります。

自動露出(Exposure)について

はい。

docs.unrealengine.com

シーンのライティングでは前述のディレクショナルライトをはじめとする光源によるライティングのほかに、間接光(GI)や自動露出(ポストプロセス)による影響が甚大です。さらに、

Unreal Engine 4.24 以前のバージョンから Unreal Engine 4.25 以降のバージョン にアップグレードしたプロジェクトでは、自動露出に相違が生じる場合があります。4.25 以降のバージョンには自動露出の操作性と機能が大幅に改善したために、下位互換性が失われました。

 と、公式ドキュメントに記述があるように、UE4.24以前と以後では大幅にExposureのアルゴリズムが変更されています。そのためUE4.24以前で作成したプロジェクトをそのまま4.25以降で開き直すと、端的には自動露出のデフォルト値0.0が1.0に修正されているなどの状況があるのですが、プロジェクト複製の際に自動でコンバートしてくれる機能が入っているようです。

物理的に正しくしてみる

それでは「物理的に正しいライト設定」をThird Personテンプレートで試みてみましょう。

f:id:kanianthi:20201212120027p:plain

☝10,000luxの状態

はい、アウト。

え?全然だめじゃん!(知ってたけど)
そりゃそうです…2.75luxという物理的にあり得ない照度で「だいたいいい感じ」に見えるようになっていたシーンに、いきなり4000倍くらいの光量を与えればこうなります。

Unreal Engine では、ポスト プロセス ボリュームにある [Max Brightness (最大輝度)] と [Min Brightness (最小輝度)] の設定にデフォルトでピクセル輝度 (cd/m2) を使用します。物理的に正確なライティングの範囲 を設定する際は、EV100 (ISO 100 とも呼ばれる) 準拠の輝度を表すために、自動露出のデフォルトの輝度範囲を拡張することができます。これは、シーン内のライトに対して正しいルクス値を使用し、画像の白飛びを発生させずに、これらの値を自動露出で使用できることを示しています。

 ☝再び公式ドキュメント(同じページ)を見ると、こういう記述があります。

要するにゲーム用のテンプレートは物理的に正確ではないライティングをしてあるので、もしも映像作品とか厳密なPBRを行うならば、こういう設定をして対応してくださいね!ということですね。

f:id:kanianthi:20201212120648p:plain

☝プロジェクト設定→Exposureと検索し、赤枠部分を変更して再起動。

この設定によりEV100(ISO100)を基準としたライティングの再マッピングが行われるので(実質的にはダイナミックレンジを広げている)「物理的に正確なライティング」が調整しやすくなります。(後述しますが、この設定は必須ではありません)

f:id:kanianthi:20201212121058p:plain

☝EV100設定後の10,000luxなシーン(Exposure1.0)

f:id:kanianthi:20201212121358p:plain

☝100,000luxでExposure1.0

晴天の昼の太陽光下の照度ですから、若干白飛びしたりするのは当然なのでようやく「物理的に正確な感じ」になったのかなー、と思います。

ちなみに、プロジェクト丸ごともっと掘り下げて正確なライティングのサンプルが欲しい!という場合は

f:id:kanianthi:20201212121721p:plain

Epic Games LauncherのUE4ラーニングのところにある「建築インテリアレンダリング」などでいい感じの室内ライティングをサンプリングすることが可能です。

f:id:kanianthi:20201212122109p:plain

☝このシーンは室内なので1,000luxでDirectional Lightが設定されていたが、妥当な数値だと思います。また、Exposureの拡張も行われていてEV100にもとづく調整がされていました。興味深い。

そしてMeerkat!

f:id:kanianthi:20201212124430p:plain

先日Weta DigitalがUE4で作成したミーアキャットのデモ…素晴らしかったですね!
しかもこのプロジェクトがアートソースを含めて無償公開されています。フトッパラ!

多くの皆さんはミーアキャットのアニメーションやファー表現、それにUE4.26から大幅に機能強化されたControl Rigによるスケルトンとアニメーション制御に興味を注がれていることかと思いますが…さすがWeta Digital!と筆者が思ったのは、ライティング設定の素晴らしさでした。

f:id:kanianthi:20201212122916p:plain

☝Meerkatプロジェクトのシーンライト群

上記Lgt_KeyがDirectional Lightです。

f:id:kanianthi:20201212123058p:plain

Intensityは日中の砂漠を反映してか170,000luxという高照度が設定されていました。

さらに興味深いのはポストプロセスのExposure設定で、このプロジェクトでは先述したEV100の拡張が行われていません。

f:id:kanianthi:20201212123350p:plain

測光モードがManualで、露出補正の値は0.0です。

f:id:kanianthi:20201212123525p:plain

☝PostprocessVolumeのExposureをManualにした場合Cameraの値を調整する。

現実のカメラだと想定した場合、シャッタースピードはもっと速くなる気はしますが…カメラ知識があればこの辺の設定は容易いように思います。

f:id:kanianthi:20201212124201p:plain

☝ISO40でF14に設定してみた。だいたい同じ絵になる。素晴らしい。

f:id:kanianthi:20201212124329p:plain

なお、このプロジェクトのレベルには他にも様々な「レンダリングとライティングで見るべきポイント」があるのですが…とりあえず面白かったのはVisualSettings_BPというアクタが置いてありました。

f:id:kanianthi:20201212124734p:plain

☝こんな感じにコンソールコマンドを送るイベントが組まれている。

このアクタはLevel Sequenceに登録されていてSSGIやLensFlareなどを調整するのに利用されています。

ほかにも挙げだしたらキリがないほどの工夫がこのプロジェクトに投入されているのですが、ぜひさらに解析して「物理的に正確なヤツについて」のUE4応用力を高め、より高度な映像的要求に応えられるようになっていこう!と考えた次第です。

終わりだよ!

さて、明日はオンドレラさんのVR系のなにか、が来るようです。

 

AutoRigProの解説:その2 Smart編

はじめにおさらい

Blenderの有償アドオンAutoRigProを紹介・解説していく記事の第2段。
その1の記事は👇です!

https://kanianthi.hateblo.jp/entry/2020/09/12/214726

というわけで、その2です。

今回はヒト型キャラクタにAutoRigProを設定していきましょう。

Blenderのバージョンは記事を執筆時点で2.83または2.90を使用。
AutoRigProは2020年9月12日現在3.54.14が最新版です。

f:id:kanianthi:20200912234115p:plain

BlenderのLayout作業スペースでAutoRigProタブを選択したところ。一番上のパネルでRIG、スキン、その他と大きな機能の項目を選べる。

Smartの準備

この手の「一発リグセットアップ機能」は他のDCCにあるリグプラグインなどでも見かけます。あるいは…Adobeが買い取ったMixamoのセットアップも(MIxamoの場合リグではなくスケルトンを一発バインドするのですが)ご存じの方は多そうですね。

先に結論から言ってしまうと、AutoRigProのSmart機能「かなり使える」と言えます。もちろん、この後の微調整は必要ですが文字通り「かんたんな操作」でとりあえず欲しい位置にベーススケルトンを生成してくれるのは超便利です。

では、手順。

まず最初にキャラクタメッシュを用意します。
今回は某ゲームコンテスト用に用意したオリジナルキャラクターの「Nuts(ナッツ)」を使います。シンプルで四肢のバランスが伸び伸びしているため、ゲームエンジンに持って行った際に見映えのする動作が可能です。

f:id:kanianthi:20200912235434p:plain

キャラクタメッシュのトランスフォーム

☝はNutsのTRS(トランスフォーム)をプロパティパネルから確認したところです。
初心者の方はこういうところでハマりがちですが、必ずTRSはこのように「位置と回転はゼロ、スケールは1」になっていることを確認してください。

トランスフォームが入ったままだと正常にウエイトが入らなかったり、スキニングとは直接関係ないですがUV展開が正しくできなかったりなど様々な不具合の原因になるのでしっかり適用(ctrl+a)する癖をつけておきましょう。

また、このキャラクターの場合髪の毛メッシュ(Hair)だけは身体と別オブジェクトですが、たとえば頭部は胴体以下と別とか、腕だけ別とか、そういうパーツ分け(オブジェクトとして分離されている)をしていても大丈夫です。

Smart開始

それではあらためて、キャラクタのメッシュを選択します。パーツがオブジェクト分離されている場合はShiftですべてのパーツを選択しておきます。そのままGet Selected Objectsボタンをクリックします。

f:id:kanianthi:20200913105330p:plain

Add Chinまで指定したところ。

すると、TurnボタンとAdd NeckボタンがUIに出現するので首の付け根に◎を置きましょう。同様にして肩、骨盤と指定していき、最後にAdd Anklesで足首の位置を指定します。

f:id:kanianthi:20200913105600p:plain

Smart機能で足首まで位置の指定ができたところ

 

f:id:kanianthi:20200913105731p:plain

上から手の指を何本検出するかの指定。Voxel法による体の部位検出の設定、フェイシャルボーンを設定するか?の指定、ベーススケルトン作成ボタン

 

f:id:kanianthi:20200913110006p:plain

「Go!」した結果。自動的にReference Bonesが作成される。

f:id:kanianthi:20200913110220p:plain

Go!した結果2:ミトン形状の手や太い足首もかなりいい感じに検出してくれているのが分かる。

☝のスクショで示したように、AutoRigProはかなりイイ感じに骨格ボーンを生成してくれます。特に今回のような2本指でも平気で検出してくれるのはありがたいですね。

以上の操作でSmartを使った基本のスケルトン生成は完了です。

Edit Reference Bonesしよう!

続いてSmart後に自動的に入るEdit Reference Bonesでスケルトンの微調整を行います。ここで行う設定と調整によってリグの仕様がほぼ決まるので、うまくいかなければ何度でも行ったり来たりすることになります。

まずは、背骨の数を変更しましょう。

標準だと背骨は骨盤を入れて3本が生成されますが、UE4のHumanoidに設定を合わせると4本背骨が必要です。

f:id:kanianthi:20200913111338p:plain

背骨のチェーン(Limb)という。のどれかを選択してLimb Optionsから設定を行える。他の関節部位も同様。

☝のスクショで分かる通り、背骨のチェーンのどれかひとつの骨を選択しLimb Optionsから背骨の数を設定できます。ちなみにLimb(リム)というのは「一連の関節の部位」のことをそう言います。単なるボーンのチェーンと違い、LimbというときにはIKやFK、ツイストやその他のコンストレイントを含めた「リグとしての部位」を呼んでいることが多いように思います。

背骨の数を4つにできたら、続いて腕と足のツイストボーンの数を設定します。

f:id:kanianthi:20200913112510p:plain

腕のツイストボーンを2本に増やしたところ。標準だと1本(2分割)

腕と足はAutoRigProのデフォルトで2分割のツイストボーンは設定されています。しかし、後述しますがゲームエンジン出力用のキャラではデュアルクオータニオン(体積を維持オプション)が使えないため、手首のひねりで破綻しやすいことから腕はツイストを2本以上に増やしておくのが無難です。

なお、ちょっと不親切ですがLimb Optionsの設定は左右独立しているため、両腕について同じ設定を行う必要があります。これは脚も同様です。脚についてはツイストを増やさなくても(よほど激しい足のねじりポーズを取らない限り)大きな問題は出ないものと思います。

骨格の微調整

続いて各骨の位置や角度を調整します。

f:id:kanianthi:20200913113437p:plain

骨の微調整をするときは八面体とスティックなどを切り替えながら作業すると正確な位置に骨を置くことができる。

それでは骨格を微調整しましょう。
このとき、うっかり背骨や頭の骨をX0から動かさないように注意してください。

f:id:kanianthi:20200913114458p:plain

身体の正中線にある骨と鎖骨を調整しているところ

☝のように、正中線(体の中心を通る線)の骨から調整します。

骨盤の位置を若干下げ、肋骨を大きくしたら、残りの背骨をできるだけ等間隔にして側面から背骨の「S字湾曲」を形成します。

この時、実際の人体だと背骨は背中側を通るわけですが3Dモデルでそれをやりすぎると綺麗に曲がらなくなるので真ん中に寄せましょう。S字湾曲についても「立たせる」ことを意識しないと他からアニメーションをリターゲットする際に極端なポーズになりがちなのでやり過ぎ注意です。

f:id:kanianthi:20200913115337p:plain

☝鎖骨を調整しているところ。マニピュレータを使用。

鎖骨の調整では、ある程度人体に近づけて首の根元から伸びるようにするとうまくいくことが多いです。前後の位置も調整し、上腕に向かって素直に繋がる位置を探します。

Blenderでは慣れるとなんでもGで動かしたくなりますが、こうした作業ではマニピュレータが活躍すると思います。グローバル座標またはノーマル座標を使い分けると絶対座標とボーンのローカル軸に沿った編集を切り替えられるので便利です。

f:id:kanianthi:20200913115831p:plain

☝つま先の調整

つま先の骨はデフォルトの角度でも十分に使えますが、アニメーションをリターゲットすることを考えるとスクショのようにしておいたほうが無難と言えます。

また、足首の関節位置(くるぶし)はかなり低い位置に置いたほうが「説得力のある足首」になります。☝のスクショは足首を設定する前の状態です。

f:id:kanianthi:20200913120605p:plain

☝足首調整中。こうした調整はリグを生成して自動スキンを終えてから何度でも戻ってきて再調整する心づもりで作業するのが良い。

鬼門!四肢の位置とロール角設定

さて、これが難関です…。

f:id:kanianthi:20200913121011p:plain

AutoRigProのロール角度は腕と足の「チェーン角度」で決まる。

☝のスクショをご覧ください。

Blenderのボーンロール角度は編集モードからトランスフォームにある「ロール」で設定できるのが通常です。しかし、AutoRigProではこの設定を無視して「腕または足のつながっている角度」からロール軸を割り出す仕様なのです。

そのため、X脚やO脚では極端な位置にIKポールが設定されてしまうなどの問題が起きやすいです。また膝や肘をFKで回転させる際にも、モデルの設定とは違う角度で曲がることになりやすいため、慎重に作業する必要があります。

f:id:kanianthi:20200913121910p:plain

Show IK Directionsを使っているところ

股関節の位置はわりと体の側面に寄せることで綺麗に動かすことができますが、それをすると下肢がX脚状になってしまい膝の回転角度(ロール軸)がおかしくなってしまいます。そこでスクショにあるShow IK Directionsをチェックすると膝の向き(IKポールの角度)が表示されるようになるので、これを見ながら脚の角度を設定すると良いでしょう。

その結果、膝の関節位置が膝小僧の中心からズレることになり気持ちが悪いですが、本物の骨ではないので(ある程度は)大丈夫です。

f:id:kanianthi:20200913122555p:plain

おまけ:膝関節の位置を側面から

f:id:kanianthi:20200913122653p:plain

おまけ2:股関節(大腿骨の頭)の位置

f:id:kanianthi:20200913122904p:plain

同じようにして肘の関節位置も設定する。

キャラクタ初心者にとっては手探りが多くて大変ですが、何度でもやり直すつもりで作業すればひとつひとつの調整はさほど難しいものではありません。

むしろここで関節の位置をしっかり試行錯誤しないで、ウエイト調整にまい進するほうが「はるかに悲劇的」です。関節位置さえしっかり調整できていれば、ウエイト調整は基本の人体であれば30分もやれば十分な作業です。

AutoRigProでは「ワンボタンで自動ウエイトを入れたり解除したりできる」ため、うまくいくまで何度でもこの関節位置の調整を行いましょう。この時、必ず「Edit Reference Bonse」まで戻ることを忘れずに!

ついにリグ生成!

f:id:kanianthi:20200913123610p:plain

Match to Rigボタンの位置

各調整が終わったら…いよいよリグを生成します。

非常に簡単で、スクショのボタンをクリックするだけです。

f:id:kanianthi:20200913123954p:plain

リグを生成後に重要になる各UIに赤枠をつけた。

いとも簡単にリグが生成されました。このときアーマチュアのプロパティパネルから「ビューポート表示」の「最前面」にチェックを入れておくとキャラクタメッシュに埋もれたボーンをレントゲンのように表示できるので便利です。

また、AutoRigProに慣れたらセカンダリコントローラーを追加しても良いでしょう。
Twistコントローラーを追加するのがBest!と書いてありますが、通常はAdditiveまでで十分だと思います。また、ベンディボーンにAutoRigは対応していますが、これはBlenderの独自仕様であってFBXでエクスポートしたりゲームエンジンに持っていくことはできないので(ぼくのワークフローでは)使いません。

それと、これが最も大事なことなのですが、UE4やUnity対応キャラクタにしたいならば、必ずExportパネルからCheck Rig→Fix Rigを行ってください。

これがいったいなにをFix(修正)しているのかというと、ボーンのストレッチ(伸縮)機能をカットしています。ストレッチはボーンの「不均一スケーリング」で実現している機能なのですが、これを行うとFBXの仕様上骨の回転角度に影響を与えてしまうため、ゲームエンジンには持って行かないのが無難です。AutoRigProはこうした部分を自動化してくれているのも大変便利です。

また、繰り返しになりますがEdit Reference Bonesから、いつでも骨格の調整作業に戻れますので、ウエイトで悩むより関節位置を微調整するほうが「幸せになれる」ことを再度強調しておきますね。

スキニング

f:id:kanianthi:20200913125747p:plain

AutoRigProで独自スキンバインド(スキニング)を行う。

それではスキニング作業に入りましょう。
AutoRigProでも選択順序はBlender標準と同じで、まずスキニングしたい対象のメッシュを選択します。複数ある場合はShift選択です。次にリグを選択して☝のスクショにある「スキン」タブからBindボタンをクリックすれば完了です。

このときVoxelizeを使うと簡易ボクセル法によるAutoRig独自のウエイト設定が使えるようになります。このボクセルスキニングはパーツが分解されているキャラクタには特に有利です。ただし、指先などの細かい部分でうまくいかないことがありますので、そういうときはVoxelizeをオフにしてBlender標準のヒートマップウエイトを使う(特に設定することなく使えます)と良いでしょう。ちなみにヒートマップ法も十分に優れた自動ウエイトのアルゴリズムです。

なお、Specialsにある「体積を維持」はデュアルクオータニオンと言って非リニア変形を実現する機能で大変便利ですが、処理負荷が高いなどの理由でUE4をはじめとするゲームエンジンでは対応していません。ですのでこれもチェックを外しておきます。

f:id:kanianthi:20200913130639p:plain

バインドを行うと自動で頂点グループが生成されてウエイトが入る

f:id:kanianthi:20200913130854p:plain

☝キャラが動くようになった!

バインドを行うとポーズモードからキャラが動かせるようになっているのが分かります。好きなように動かしてみて、変形におかしな部分がないか確認しましょう。

もしもおかしい部分を見つけたら、ある程度の調整まではそのままリファレンスボーンを調整することで修正可能ですし、ウエイトを一度外したい場合にはUnbindボタンをクリックすることで「一発ですべての頂点グループを取り除くことができる」のでこれも激しく便利です。

f:id:kanianthi:20200913131404p:plain

変形ボーン(スケルトン)はボーンレイヤーの最後に格納されている。

骨の微調整だけではどうにもならない箇所については、最終的にウエイト調整を行うしかありません(モーフを使った補正は次回説明します)。

基本的にウエイト調整はこの変形用ボーンにしか行わないので注意してください。

最後に髪の毛オブジェクト

さて最後に、このキャラクタの髪の毛もバインドしておきましょう。
AutoRigProの自動バインドに任せても良いのですが、今回のように単純なキャラクタでは頭のボーンに単純バインドしてもらえるだけで良いので、すべてのボーンについて計算することは無駄と言えます。

f:id:kanianthi:20200913132008p:plain

Hairオブジェクトにhead.x頂点グループを作成した。

そこで☝のように頂点グループを名前「head.x」で作成します。
この名称はAutoRigProの命名規則で「.x」は身体の中心にある骨のことで、プレフィックスのない「head.x」は変形可能な頭のボーンの名前と一致しています。

ポリゴンの編集モードからaで頂点を全選択し「ウエイト1」でAssignすればウエイトペイントすることなくすべての頂点に最大値である1が入ったウエイトが入ります。

こうしたウエイト入れのことは、まったく変形しないウエイト調整であることから「リジッドバインド」と呼ばれています。ロボット関節では良く使う手法ですので知らなかった方は覚えておくと良いでしょう。

ここまでできたらオブジェクトモードに戻り、メッシュを選択してからShiftでリグを選択しctrl+pから出てくるペアレント設定で「アーマチュア変形」を選択すればHairがリグにバインドされます。

f:id:kanianthi:20200913132842p:plain

すでに頂点グループがある場合「アーマチュア変形」を設定するだけでメッシュがバインドされる。

f:id:kanianthi:20200913133116p:plain

☝いろいろできたー!の図

まとめ

以上の工程でAutoRigProのSmart機能を使ってヒト型キャラクターのリグを生成してスキニングし、動かせるようになるまでを一通り解説できました。

AutoRigProはこのほかにも便利な機能が満載されているので、解説記事はもう少し書くつもりですが「基本の基本」は網羅できたと思います。

それでは次回は、Remap機能を紹介したいと思います。





      

AutoRigProの解説:その1 概要編

はじめに

おひさしぶりです、なんです。
今回はBlenderの有償アドオンとしては特に知名度が高く、プロの現場でも採用例の多いプリセット・リグである「AutoRigPro」について解説しようと思います。

恐らく長くなるのでいくつかの記事に分けてお話しすることになりますが、まずは概要からざっくり入っていきましょう。

AutoRigProとは?

名称からも分かるとおり「自動でリグを設定してくれるプロっぽいツール」です。そのまんまです。このアドオンをBlenderに導入することでリグの設定が自動化されて便利になります。

購入の際はBlenderMarketに行くと常時トップページで紹介されているくらいの人気ものです。

https://blendermarket.com/products/auto-rig-pro

価格は40ドル。
Blenderの有償アドオンとしては高価な部類かも知れませんが…他の商業3D DCC用アドオン・プラグインと比較するとびっくりするレベルでリーズナブルです。

具体的な機能については…

  • Smartという一連の操作で数回関節位置でマウスクリックすればヒト型リグを自動生成してくれる。
  • ヒト型リグ以外に四足(ウマ型、イヌ型)リグや鳥タイプのリグ・プリセットが用意されている。
  • その気になれば「骨ひとつから」AutoRigProでリグを生成することも可能
  • わりと使えるフェイシャルリグ(ボーンベース)も自動生成できる
  • 独自のスキニングメソッド(Voxel法をアレンジしたもの)が統合されている
  • プリセットで変形補正用の補助リグ、ツイストボーンを追加できる
  • シェイプキーと連動したボーン制御が可能
  • 独自のアニメーションリターゲット機能を実装している(ReMap)
  • ゲームエンジン向けに独自のFBXエクスポーターを統合している(Unreal Engine4とUnityに対応)

などなど…Blenderには標準でRigifyというリグ・プリセットも用意されていて、これもなかなかに機能的ではありますが、特にゲームエンジンとの連携や独自のスキニングメソッドという点ではAutoRigProが優っています。(有償なんだから当然といえば当然ですが)

さらに特筆すべきは、このアドオンの作者であるArtelさんが「めちゃくちゃ熱心」に開発と更新を続けていて、機能の追加だけではなくバグFixにも「おそろしく勤勉」なことは挙げておくべきでしょう。
※ただしその結果としてアドオンの更新で互換性が保たれなくなることもしばしばありました。

なにはともあれ、ぼく個人のパーソナルワークで使い始めたのがきっかけでしたが、今ではぼくが勤めるIndie-us Gamesでも標準リグとなっていますし、弊社の取引先さんの一部でもAutoRigProをスタンドダードリグとして採用する事例が増えています。

しかしそもそも「リグってなんだよ?」とか「ボーンとどう違うの?」という疑問があると思います。なので、まずはそこからかいつまんでお話ししていきましょう。

リグとボーン・スケルトンの違い

Blenderではボーンを追加するとき「アーマチュア(Armature)を追加」というコマンドでシーンにボーンを追加できます。
アーマチュアというのはそうやって追加された「骨(ボーン)をまとめたもの」という意味です。データとしてひとつの塊、階層になっている、というわけです。

一般にBlenderでいうアーマチュアのことを「スケルトン」と呼びます。骨格(骸骨)という意味ですね。ひとつのスケルトンは頭蓋骨だとか背骨だとかという細かいパーツを含んでいます。

f:id:kanianthi:20200912184731p:plain

ボーンとスケルトン(アーマチュア

ではリグってなんでしょう?
3Dソフトウエア特有の言葉であると勘違いされている方がたまにいるのですが、リグは「なにかを動かすための仕組み」のことです。映画などでカメラをクレーンで動かしたりするための仕組みを「カメラ・リグ」と呼んだりしていたことから、3Dの世界でもリグという単語が普及したのだと思います。

つまり、リグというのは「骨・関節」または「キャラクタ全体」を動かすための仕組みのことです。それは「リグ用のボーン」だったり「コンストレイント」だったり「ロケーター(BlenderではEmpty)」だったりもっと複雑な「リグ用スクリプト」だったりします。

Blenderでは「変形可能」というフラグがボーンのプロパティにあって、これをonにしてウエイトをメッシュの頂点に設定することでボーン変形が可能になります。
一般にスケルトンとはこうした「変形可能ボーン(デフォームボーン)の塊」のことを指します。そしてスケルトンを動かすために用意する「上位の階層」(またはすべてを統合した全体)をリグと呼ぶわけです。

初学者の方にとってボーンとリグの違いはなかなか分かりにくいものと思いますが、だいたいのところはこの説明で通用するはずです。

f:id:kanianthi:20200912211247p:plain

AutoRigでは赤枠で示したレイヤーにコントローラーを格納する。緑枠で示したレイヤーには変形用のスケルトンが格納されている。FBXエクスポートでゲームエンジンに出力するのはこのスケルトンだけになる。

f:id:kanianthi:20200912211009p:plain

画像はAutoRigが自動で生成してくれるコントローラー。コントローラーは実際のところカスタム設定をしたボーンなのだが、コントローラーはリグなのでウエイトをつけない。

リグの難しさ

ここまで読んでいただければ「リグって難しそうだな」という雰囲気は伝わったように思います。実際、プログラムやスクリプトに詳しくないアーティストが一人でリグを構築するにはかなりの勉強をしなければなりません。

そのため、様々な3D統合ソフト(DCC)にはプリセット・リグが用意されているのですが、仕様が標準ボーンとは違う(プラグインとして提供されているため)など、サクっと使うには良くても、カスタマイズに制限があったり、ゲームエンジンのことは考慮されていないなど、不便な点も多くあります。

しかし、AutoRigproでは標準のRigifyと同様にBlenderの標準ボーンを使ったリグを構築するため、もともと自由度の高いBlenderアーマチュアの機能を生かした設定が可能です。ユーザーが任意の衣装や髪の毛、その他物理シミュ用の追加ボーンを設定することも可能ですし、それをゲームエンジンにエクスポートするための設定もできます。

f:id:kanianthi:20200912211613p:plain

アニメーションではAutoRigProが自動生成するコントローラーにキーをつける。コントローラーは変形用のスケルトンをアニメートさせ、FBXエクスポートする際にはアニメーションのキーをスケルトンに自動ベイクしてくれる。

AutoRigをはじめとしたリグが「分からない」という人の多くは、これらコントローラーと変形用スケルトンの違いが分からない(知らない)場合が多いと思います。そのため、コントローラーに必死でウエイトをつけていたり、変形用のスケルトンにキーを打ってしまい、エラーを引き起こしてしまうのではないでしょうか。

リグピッカーについて

f:id:kanianthi:20200912212205p:plain

AutoRigProには画像のようなリグピッカー機能があるのだが…わりとトラブルの元になっていて(ぼくの)制作では使っていません。

AutoRigProに初期から実装されている機能ですが…☝のRig Pickerについては「わりとトラブルの元」で、正直使わないほうが無難である、という認識です。

リグピッカーはたくさんあるコントローラーを「分かりやすいUI画面で」パパっと選択したり設定を変更するために用意されているのですが、不具合があるにせよないにせよ積極的に利用したいひともいれば、こういうの却って使いにくいんだよね~という人がいて、ぼく自身は後者です。

この辺のUIに凝ったリグは他のDCC用リグでも多く見られるものですが…便利そうではあるものの「直接手足のコントローラーを選択したほうが直感的で手早くキーを打てる」という理由で使われないことが多いものですね…。

ちなみにRigifyだとBlender画面の右側プロパティパネルにこうしたコントローラー選択UIが用意されていますが、動作としてはAutoRigProよりも(この点については)安定している、という印象です。
※実はAutoRigProのPickerはそれ自体もカスタム設定されたボーンコントローラーです。

UnrealEngine4(UE4)との相性

残念ながらぼくはUnityについてはほとんどなにも知りません。会社もUE4を専門としているので業務でUnityを利用することはほとんどないだろうと思います。

一方で、UE4については専門ですのでAutoRigProとの連携についてはたくさん知見を持っています。当初はBlenderUE4ではかなり骨の仕様が違うことから細かい不具合も多く見られましたが、Blender2.8x時代になってからは「少なくともUnreal Humanoid対応において」問題はなくなった、という認識です。

f:id:kanianthi:20200912213749p:plain

AutoRigPro独自のFBXエクスポーター

☝はAutoRigProに実装されている独自のFBXエクスポーターの設定部分です。
ここではUE4マネキンにボーン(ジョイント)名称を合わせてくれるほか、ゲームエンジンにエクスポートすると不具合の原因となる「ボーンストレッチ」を自動的にカットしてくれたり、ボーンの軸をUnrealケルトンと合致させてくれるなど、BlenderUE4用キャラクタを作成するうえで不可欠な設定を行うための配慮がされています。

わりと最近まで、耳や尻尾という補助ボーンの軸だけが合わないという問題があったのですが、それも解消してくれたのでUE4対応では不可欠なアドオンになりました。

この他にも、BlenderUE4の間で生じるスケール問題や、rootボーンの回転問題、rootモーションの出力安定性や、任意のActionだけをエクスポートできる機能など、Blenderの標準機能だけで対応しようとすると(知識なしでは)かなり難易度の高い問題をカバーしてくれますので、非常に便利で有用なアドオンと言えるでしょう。

次回は…

さて、長くなりましたので「その1」はこのあたりで終わりにします。

次回からは、いよいよ具体的なセットアップを通じてAutoRigProの機能や豆知識について触れていこうと思います。

そんなの待てるかー!という方のためにAutoRigPro作者さんによるドキュメントへのリンクも貼っておきますね!

http://www.lucky3d.fr/auto-rig-pro/doc/install.html

さて、それではまた次の記事でお会いしましょう。

アーティストのためのまてりある式にゅうもん

こんにちは、なんです。
この記事はUnreal Engine 4 Advent Calender 2019その2

qiita.com

の8日目の記事になります。

はじめに

実はこの記事、なにもUE4に限ったことではなくノード型マテリアルエディターを使ったマテリアルの作成において、どんなケースでも当てはまる「基本の考え方」について解説するものになります。

趣旨

アーティストは数字が苦手…残念ながら3D CGやゲームエンジンに入門したてのアーティストでは特に、マテリアル式の意味をさっぱり理解せず、なんとなく「これを繋げるとこうなる」的に覚えてしまっていたり、そもそも写経だけで自分ではマテリアル式を組み立てる方法さえ分からない、というケースが散見されます。

そこでこの記事では、マテリアル式で使う基本的な演算ノードについて解説を行い、数式によって見た目や色がどう変化するのか?についてお話ししたいと思います。
※ちなみにこの辺の知見って基本すぎるし分かるやろ?ってコンセンサスなのかほとんどちゃんと取り上げているソースを見ないのがちょっと残念。

Part1

それでは早速UE4でかんたんなマテリアルを組みましょう。
どれくらい簡単かというとこれくらい簡単です。

f:id:kanianthi:20191207213501p:plain

M_Advent

このマテリアルはシェーディングモデルをUnlitに設定しました。
Unlitはベースカラーやメタル、ラフネスといった質感を持たないエミッシブカラー(自己発光色)だけで見た目を作るマテリアルです。 

左に置いた赤いノードはVector Parameterです。「Color」となっていますが、名前を好きにつけられるのでぼくがColorと入力したのです。YasaiでもOnikuでもなんでも構いません。とにかく意味しているのは4つの要素を持つベクターパラメーターである、ということだけです。そしてこの、ベクターパラメーターこそアーティストを最初に混乱させるノードだとぼくは思います。

なぜならこの、ベクターパラメーターは「色」を表現しているからです。

f:id:kanianthi:20191207214045p:plain

Vector Parameter

拡大しました!わかりやすい!
Param(1,0,0,0)となっているのが分かりますね。そう、この数値の意味はRGBになぞらえて、Rを1、Gを0、Bを0にしたので赤いのです。最後のグレーの場所はアルファ(透過)だと考えてください。つまりRGB+Aです。

UE4のマテリアルノードでは「色」というノードを使わず、このようにベクターパラメーターを用いて色を表現します。

それではベクターパラメーターってなんでしょうか?ベクターとはベクトルのことです。数学でベクトルとか聞いたことはありますよね。もうこのベクトルという名称が出てきただけでも苦手意識を感じてしまうひとがいるかもしれません。

数値は基本的に「量」を表します。つまり大きさです。
誰でも1より10が大きいことは理解できると思います。0.1より1.0が大きいことも理解できますよね。

UE4においても、他のノードグラフにおいても、単独の数値があったなら、それは同じように大きさを表しています。今回の「Color」と名付けたベクターパラメーターでは、数値の大きさはRGB(+A)各チャンネルの「明度」をコントロールしています。

それではこの数値を複数用意したなら、なにを表現できるでしょうか。

f:id:kanianthi:20191207220025p:plain


↑簡単なグラフを作ってみました。
このグラフを2次元の平面と考えることができます。

すると(0,0)はこの平面の原点座標になります。(1,1)はXとYの座標が1になる場所のことです。勘の良い方ならもう気付いたかも知れません。

同様にして数値をひとつ増やして(1,0,0)と表現すると、3D空間における位置、つまり座標を表現することができます。驚きませんか?これが3Dアーティストにとって最も身近なベクターパラメーターの意味です。つまりRGBという色を表現している3つの数値を使って、3次元空間における位置を表すことができるのです。

ベクターパラメーターとは?

もう一度ベクターパラメーター、あるいはベクトルについて考えます。
ちょっと調べてみると…

大きさだけでなく、向きももった量

要素を(縦または横に)一列に並べたもの

というのがGoogle先生の最初に出て来ました。
先ほどのグラフを思い出せば、ベクトルが向きを表現できることは理解できますね。また、向きや位置を表現するには数値が二つ以上ないと難しいことも分かります。
もっと3Dアーティスト風にいえば、RGBで表す色も3D空間の頂点の位置もベクターパラメーターであり、それは単に数値を2つとか3つとかそれ以上とか並べたものだ、ということです。

ではこういう捉え方はどうでしょう。
『複数の数値の組み合わせであるベクターパラメーターによって、色や位置や方向を表現することができる。なにを表現するかはその時の都合で良い』

↑思考が柔軟じゃなかったり、固定観念に囚われている(色は色でしかないとか)と、この考えが案外分からないというか、捉えられません。また、アーティストとエンジニアの間でコミュニケーション不全が発生してしまう原因も、この辺にあるのではないだろうか?とぼくは考えています。

PART2

スタート地点を(たぶん)過ぎたので先に進みましょう。まさか…すでに混乱していないですよね?
ここからが本題です。

f:id:kanianthi:20191207223852p:plain

先ほどまではベクターパラメータの数値は(1,0,0,0)でした。これを(100,0,0,0) にしてみました。すると…

f:id:kanianthi:20191207224011p:plain

マテリアルプレビューが変化して、このようにエミッシブによる発光表現が得られます。これは、パラメーターの意味が分からなくても「エミッシブを上げたので光った」という風に理解しやすいですね。

ではフォトショップで…

f:id:kanianthi:20191207224443p:plain

50%のグレー

↑のように50%のグレーで背景を塗りつぶしました。

f:id:kanianthi:20191207224657p:plain

次に↑のように背景を複製してレイヤーにし、乗算で重ねてみました。
その結果はどうなるでしょうか?

Photoshopで絵を描いたり、写真の編集をしていればご存じですよね。はい、元のグレー画像よりも暗いグレーが表示されるはずです。

しかし多くのアーティストは「乗算すると暗くなる」ことを知っていますが「なぜ乗算すると暗くなるのか?」は分からない、と答えます。「そういうものだから」で済ませているからです。

まったく同じ状況をUE4のマテリアルで表現することができます。

f:id:kanianthi:20191207225349p:plain

0.5×0.5

上で「Multiply」とあるのが「乗算ノード」です。単純にかけ算をするための演算ノードになります。そしておそらく、最も頻繁にマテリアル式で使うノードとも言えるでしょう。

色についてはグレースケールではなくRGBカラーで考えると、前述のフォトショで作成したように50%のグレーはRGBそれぞれが.5になります。各色8bitの256階調であれば128(または127)ですね。

■追記■
Photoshopなどで各色8bitで24bitカラーの場合、中間グレーは128になるので計算式は128×128なのでは?という疑問はもっともです。しかし実際の計算は0から1.0の間で行い、カラー設定によって2bit(白と黒しかない)や8bitあるいはHDRIなどで使う各色32bitまでの「階調(帯域)」に当てはめているのです。

そして「乗算」というのは「かけ算」ですから
0.5×0.5=0.25
という答えが得られます。

1が真っ白、0が真っ黒で中間のグレーが0.5です。数値は「明るさ」を表していますので0.5に0.5を掛けたら0.25になり、暗くなるのです!

※エンジニアやテクニカルな事象を理解しているアーティストにとっては「それ知らなかったんですか?」ということかと思いますが、実際に乗算ノードの意味を説明できる初学者アーティストは少ないです。なので、これをヒントに「エンジニアとアーティストのコミュニケーション不全」について理解が深まれば、というのがこの記事の本当の主題であるかも知れません。

PART3

さらにフォトショップでこんな画像を作ってみました。

f:id:kanianthi:20191207231013p:plain

白黒のマスク

周囲は真っ黒なので数値にすると0で、真ん中の丸い部分は真っ白なので1です。
これを512×512のテクスチャとしてUE4にインポートします。

f:id:kanianthi:20191207231441p:plain

さらにノードをこのように組んでみました。

f:id:kanianthi:20191207232101p:plain

マテリアルのプレビューを分かりやすく立方体にするとこうなります。

f:id:kanianthi:20191207232205p:plain

Multiply

また、Multiplyノードの右上にある△をクリックすることで演算結果をプレビューすることもできます。

なにをしているのかというと「白黒マスクで指定範囲に色をつけた」のですが、今までと同様、こういうマスクを使って色を塗れば、指定範囲に色がつくことは知っていても「なぜ指定範囲だけに色がつくのかの理由」を説明できるひとは少ないのではないでしょうか。それではあかんのです。

そこで、このように考えましょう。

f:id:kanianthi:20191207233023p:plain

Excelで白黒マスクに乗算を数値化したもの。Xの列は1が白で0が黒。Yの列はXに5をかけ算したもの。0になにをかけても0のままなのに対し、1に5をかければ当然答えは5になります。(数式に直すとY=5Xです)

さらに重要なこととして、Photoshopでの乗算は「白より明るい色」が存在しないので乗算の結果は必ず「もとより暗い色」になります。最大値は1×1なので1なのです。

しかしUE4での色はパラメーター(数値)に過ぎませんのでどんな数値でも掛けることができます。その結果…

f:id:kanianthi:20191207233752p:plain

ベクターパラメーターを(100,0,0,0)にすれば…

f:id:kanianthi:20191207233844p:plain

このような結果を得ることができます。
Photoshopでは乗算によって元の色より明るい色を作ることができません。しかしUE4を始めとするノードグラフ式のマテリアル(シェーダー)では1より大きな数をパラメーターとして利用することができるため、乗算によって「元より明るい色」を作成することができるのです。

PART4

それではもうひとつ基本的な「算数」をしましょう。

f:id:kanianthi:20191207234508p:plain

↑もまたExcelで簡単なグラフを作りました。

緑で示した列がもとのグラフでY=Xです。数値を単純に整数で増やしたものなので直線グラフ(リニアなグラフ)になります。

青い列はこれに+5をしたものです。(数式ではY=X+5)
右側のグラフを見ると、元のグラフに対して+5をしたものは「上側に移動」しているのが分かると思います。この「上側に移動」したのはなんでしょうか?そう、明るさなのです。

UE4でのノードグラフで加算は「Add」になります。

f:id:kanianthi:20191207234959p:plain

Add演算ノード

f:id:kanianthi:20191207235037p:plain

マテリアルプレビューの結果は↑の通りです。

その意味を考えると、先ほどの乗算では0になにを掛けても0のままでしたから黒い部分は光りませんでした。ところが、今度は加算…つまり足し算ですから0+100=100です。そのため、マスクを使うケースでの加算はうまい利用法がすぐには思いつきません。

しかし、先にExcelでグラフの例を示しましたが、加算を使うと「グラフを移動(シフト)させられる」ことが分かっています。

そこで

f:id:kanianthi:20191208000245p:plain

TexCoordinateに加算

マテリアル式をこのように変えて見ました。

ちょっと要素が増えましたね。
左上にある赤いマテリアルノードは「Texture Coordinate」というものです。これはUV座標を操作するためのもので、テクスチャをタイリングしたり、UV座標で「動かす」ために使います。
また「UV」と書いてあるのは「スカラーパラメーター」です。定数(Constant)に対して変数(Parameter)があるのですが、スカラーパラメーターは単純な数値の大小を与えるのに使います。

■追記■

ベクターパラメーターが座標や向きを表現できるのに対してスカラーパラメーターは単純な数値の大小、つまり「量」を与えます。ここでスカラーとは英語(正確にはラテン語)のScaleから来ていて「Scalar」と書きます。Scale(スケール)が拡大縮小を表現するように、スカラーはベクトルをかけ算したり足し算したりするときに使います。

先ほどのベクターパラメーターを「Color」と名付けていたように、パラメーターの名前は好きなようにつけることができます。分かりやすいように「UV」としましたが、これもSushiでもNikuでも効果は同じことです。

f:id:kanianthi:20191208000613p:plain

TexCoordに0.2を加算した結果

どうでしょうか。
この結果はTexCoordによって与えられる「もともとのUV座標」に対してAddつまり加算で0.2を足して、白黒マスクのUV入力につなぎました。その結果、キューブのメッシュに投影されるマスクの座標が動いたわけです。


加算はPhotoshopであれば単純に「元の色に対して色を足し算する=明るくなる」結果が得られますが、UE4では色を明るくする以外に、UV座標を動かす操作、つまり「座標ベクトルを移動させる」ことにも使えます。

ではさらに…UV座標というのは横をU、縦をVと定めたテクスチャマッピング用の座標系であることは3Dアーティストならご存じですよね。通常は0,0から始まり、1,1でひとつのUV平面を形成しています。

つまりUVを操作するならば…U座標とV座標をそれぞれ別々に動かせたほうが便利そうですね。

f:id:kanianthi:20191208001453p:plain

Append VectorでUとVを合成

さらに見慣れないノード式が出て来ましたが、これはAppend Vectorというもので、二つの数値をベクトルとして並べてくれる(合成する)ものです。Appendをいくつも重ねればもっと多数の要素からなるベクトルを作ることもできます。

このマテリアル式では「U」と「V」というスカラーパラメーターを用意して、Appendによりベクトルとして合成し、TexCoordのUV座標にAddで加算を行っています。

Uは0になっているので横方向には動きませんが、Vに0.2を入力してあるので縦方向にマスクが移動するはずです。

f:id:kanianthi:20191208002554p:plain

UV座標のVだけを加算で動かして見た

いかがでしょうか。
予想通り、キューブに投影されたマスクが縦方向に移動したのが分かると思います。
また、パラメーターはマテリアルインスタンスで自由に操作したり、ダイナミックマテリアルインスタンスを作成することで、ゲームプレイ中でも動的に動かすことが可能です。

このような仕組みを使えば、エフェクトでUV座標の中でテクスチャを動かしたりすることができるのです。

最後に

今回は長くなりましたのでここまでにしますが、ほかにもUE4のマテリアル演算にはPower(べき乗)やDivide(割り算)、さらにFloor(切り下げ)やdot(内積)などがあります。
しかし、マテリアル式を考えるための基本は、今回の記事で示した通りです。すべてはその応用に過ぎません。

それぞれ意味が分かってしまえばそれほど難しいものではありません。数学や幾何学が苦手だった方でも、じっくり考えればきっと理解できると思います。好きなゲームを作るために「なぜそうなるのか?」という理由を理解することはとても大切です。

明日は

0xUMA - Qiita

 さんによる「ちょっとしたの」ということです。
お楽しみに!

えびふらいのうごかしかた

こんにちは、なんです。
この記事はUnreal Engine 4 Advent Calender 2018その2

qiita.com

 の6日目の記事にあたります。

はじめに

UE4には様々な方法でアクターを動かす方法があります。
アーティストであれば、ほぼ必然的にCharacterクラスを利用して自分でモデリングしたキャラクタを動かす方法を試してみるでしょう。ぼくもそうでした。

実際UE4のCharacterクラスはとても便利にできていて、歩行、ジャンプ、飛行、泳ぐなどの移動システムが最初から用意されており、BlenderやMayaなどの3Dツールでキャラをモデリングしてリグを仕込み、アニメーションをつけてFBXに出力…それをUE4で読み込んでアニメーションBPを作成すれば…あとはThirdPersonテンプレなどにあるキャラクタBPの(スケルタル)メッシュを差し替えることで、すぐに自分で作ったキャラを操作しつつ動かし、レベル上でアクションさせることが可能です。

というわけで…とっても便利なCharacterクラスですが、できないことがないわけではありません。それが今回の記事で実現するような挙動です。それでは、ちょっと一工夫してキャラクターに味わい深い動作をしてもらいましょう!というのがこの記事の趣旨となります。

f:id:kanianthi:20181206002705p:plain

UE4のRolling Templateサンプル

UE4にはTPSやFPS、サイドスクローラーなど、様々な基本的ゲームのテンプレートが用意されています。中でも、ぼくが大好きなのがスクショにあるRolling Templateサンプルです。

Rolling Templateでは球体に対して物理的な「回転トルク」を加えることで文字通り地面を転がりまわったり、ジャンプさせて箱にぶつける、というようなアクションが可能です。
また、Characterクラスそのままだとすぐにはできない「溝に沿った移動」や「壁にぶつかって跳ね返る」などの動きが、実にシンプルなブループリントノードで実現できていることも可能性を感じるポイントになります。(アクタが物理シミュで動く球体なので当然といえば当然ですが)

そこで…エビフライのエビ・ワンさんに、物理ボールの動きをさせたいと思います。

作戦1:考え方

玉っころをエビフライに置き換えたい…その前にまずエビフライをUE4にインポートする必要がありますが、今回はそこの部分は一気に割愛。

f:id:kanianthi:20181206012122p:plain

UE4にインポートされたエビフライのエビ・ワン

f:id:kanianthi:20181206012801p:plain

アニメーションBP(イベントグラフ)

続いて、アイドルポーズ、歩き、走りをブレンドスペース1Dで作成し、スクショのように最もシンプルなアニメーションブループリントを作成しました。今回は動作をさせるところまでなのでこれで十分です。

同様にして、エビフライをメッシュにしたキャラクターBPも作成しておきますが、イベントグラフはあとで作成するのでアニメーションBPだけを設定しておきます。

f:id:kanianthi:20181206091337p:plain

ちなみにキャラクタークラスは「歩行能力を持っている」ことが特徴で、Pawnの場合は「なんらかの方法で操作・移動が可能である」ことが定義づけになります。
今回のエビフライの場合、Pawnでもなんでも良いのですが、一旦キャラクターで作っておけばアーティストにとって楽に作戦を進めることができるでしょう。

さて重要なのは「転がる玉っころの動きをエビフライになぞらせる」ことです。
しかし…単純に転がる玉っころのメッシュをエビフライに置き換えても…そのままでは転がることができません。なぜなら「玉じゃないから!」ですねw

それでは…玉っころにペアレントしてエビフライを動かしたらどうでしょう…この方法なら親(リンク元)である玉っころの移動・回転に応じてエビフライも動きます…が、やってみれば分かりますが、玉っころと一緒に回転してしまうので相当シュールな状態になります…ちがう…そうじゃない…という感じですね。

そこで、以下のように仕様を考えてみます。

  1. RollingTemplateにあるPhysicsBallBPの移動をエビフライに反映させたい。
  2. 玉っころは非表示にしよう
  3. 玉っころの転がる方向を前方向だとしよう

作戦2:ブループリントのキャスティング

エビフライのキャラクターBPで以下のようにBeginPlayイベントを構成します。

f:id:kanianthi:20181206092636p:plain

初心者アーティストがUE4のブループリントに触れ始めて、最初に戸惑うのが「アクタとアクタの参照を作ること」だと思います。代表的なのがプレイヤーのキャラクタBPとアニメーションBP間でキャスティングを行い、相互に変数や関数(イベント)を参照できるようにすることですね。

うっかりすると、このキャスティングをひとつのブループリントで何度も何度も行う羽目になります。非常に面倒ですしブループリントも美しくありません。そこで、ゲームの開始(実際にはそのアクタがレベルにスポーンしたとき)と同時に、キャストを一度だけ行い、リファレンスを変数として保持してしまい、後はそのリファレンスを対象にノードを組んでいく、という手法が使えます。

他にもブループリントインターフェースを使うなど、ブループリント間で通信させる仕組みは色々ありますが、アーティストがさっさと作りたいものを作ってプロトタイピングを行うためには、このような方法がありますよ、という例です。

次に、Tickイベントを利用して…

f:id:kanianthi:20181206094510p:plain

↑のようにボールの速度から前方向を割り出し、さらに位置を更新するためのノードを組みました。Tickは毎フレーム処理(つまり60FPSなら一秒に60回)されるので嫌われますが、PC上でプロトタイピングを行うにはとっても有効です。最終的にゲームとしてリリースするときにはエンジニアさんと相談して別の更新方法を採用するかも知れませんが、まずは「動けばOK!」の精神でイテレーションを前に進めることを考えます。

次にPhysicsBall側でもエビフライをリファレンス…というかアレしてコレする必要がありますね。今回はチュートリアルではないのでサクサク進めます。

f:id:kanianthi:20181206095825p:plain

 PhysicsBall_BpのイベントグラフにBeginPlayを追加して、Ballのワールドトランスフォームを取得してそこにエビフライをスポーンし、そのままリファレンスに入れる、というノードを組みました。リファレンス用に作る変数はSpawnActor~のノードにあるReturn Valueからワイヤーを引き出し「変数に昇格」をすれば簡単に作れます。

作戦3:仕組みはできた…あとは問題点を潰そう

以上の作業でPhysicsBall_BPにリンクして動くエビフライの仕組みができました。
しかし…このままPIE(プレイ・イン・エディタ)で動かすと、あれこれ問題があるのが分かります。

youtu.be

 UE4に限らず、ゲームエンジンでは「表示と非表示」それにコリジョン(衝突判定用の特別なボディ)について考慮する必要があります。

上の動画からわかる問題は

  1. 玉っころが表示されたまま
  2. コリジョンが干渉して操作不能になっている

という2点の問題があります。
順番に解決しましょう。

f:id:kanianthi:20181206112431p:plain

↑PhysicsBall BPのBallについては、ブループリントから制御する必要もなく常時非表示にしておきたいので、ブループリントエディタの右ペインにあるRendering項目からHidden in Gameをチェックして隠してしまいましょう。

このHiddenは、たとえばプレイヤーや敵の死亡時などにもよく使います。ブループリントからも簡単に制御できるので初心者の方は覚えておくと役立ちます。

これで玉っころを非表示にできました。
次はコリジョン同士が干渉してびゅんびゅん飛び回ってしまう問題を解消します。

この仕組みでは、実際に動いているのは先ほど非表示にしたPhysicsBallです。ですから床やその他の物体と衝突するのは玉っころのコリジョンだけで良いことになります。

そこで、BP_EbiOneのコリジョンを編集していきます。

f:id:kanianthi:20181206113535p:plain

まず↑でカプセルコンポーネントコリジョンをOverlapAllにしました。NoCollisionでも動作しますが、ゲームにするにはエビフライ側でダメージ判定などを行いたくなるのでオーバーラップできるようにしました。

f:id:kanianthi:20181206113822p:plain

続いて、BeginPlayイベントの最初で、エビフライのメッシュのコリジョンを無効にする処理を入れておきます。


えびふらいのうごかしかた:2

できました!
ついに物理ボールの動きをなぞるエビフライが実現できました。

作戦4:仕上げをしましょう

動画のように、エビフライを動かして操作することはできるようになりましたが、アニメーションがアイドルのままです。そこで、

f:id:kanianthi:20181206114549p:plain

シンプルな1Dブレンドスペースのブレンド変数であるSpeedをアニメーションBPが受け取れるようにします。これもいろんな方法があります。

というかですねw冒頭でアニメーションBPでSpeedを受け取る仕組みは組んでいましたよね…記事を書いていて今気づきましたww
だがしかし!このノードではエビフライキャラクタの移動速度だけしか受け取れません。実際に必要なのは玉っころの移動速度です。

そこで!

f:id:kanianthi:20181206115645p:plain

BP_EbiOne側からアニメーションBPの変数にアクセスできるように、ABP_EbiOneもBeginPlayでリファレンスを取得してしまいます。

f:id:kanianthi:20181206120350p:plain

BeginPlayと同じく、Tickイベントにもシーケンスを挟み、アニメーションBPのSpeed変数を更新できるようにしました。これによって、アニメーションBPで最初に作ったSpeed更新の仕組みは必要がなくなったので削除しておきましょう。


えびふらいのうごかしかた:3

以上でエビフライがPhysicsBallの動作をなぞって操作できるようになりました!
動画ではエビフライのメッシュを3倍に大きくして大エビフライにしてみました。

作戦5:今後の改良点

  1. エビフライの位置と回転をコントローラの入力操作に紐づければTickを改善できるかな?
  2. カメラを工夫すればTPS的に操作できるかな?
  3. 攻撃、ダッシュ、死亡などもあるといいかな?

などというように、ぜひ改良を試みてください。

なお、この記事で作成したプロジェクトを公開します。
ぜひ皆さんも遊んでみてください。

1drv.ms

修正版!2018年編:Blenderで作った3DアセットをUE4で利用するためのTipsあれこれ

前回記事から結局少し時間がかかってしまいました。

その間に、新潟県妙高市から引っ越して現在は大阪市のIndie-us Games所属アーティストになったりとか、公私の両面で大きな動きがありました。

この記事を書いている今日(2018年6月10日)から見て、一週間さかのぼると…

www.slideshare.net

UE4のアーティスト向け勉強会が大阪なんばで開催され、そこで登壇させていただきました。当日は技術論やTipsには重きを置かず、アーティストとしてのモノの見方や人生経験などをベースに、若いUE4アーティストやエンジニアの皆さんに、ぼくというアーティストのプロフィールを知っていただき、考えていることや目指していることを伝えることから「IP(知的財産権)を立ててコンテンツを作ること」についてお話しさせていただきました。

スライドの内容については割愛しますが、ブログではあらためて

BlenderUE4の連携で、問題ってなにがあるの?

について、あらためて紹介し、その対策などを書きたいと思います。

f:id:kanianthi:20180610152644p:plain

さて、いきなり結論ですが…少なくともBlender2.79b(最新安定版)でキャラクターをモデリングしてFBXに書き出し、UE4でアセット化するにあたって…

ほぼすべての問題が解決しています!

と、もう言っていいんじゃないかなー、と思います。
ただし、無条件にBlender最新版を利用すればすべての問題をなくせるわけではありません。前回の記事でも紹介した「Autorig Pro」の導入は必須と言えます。

blendermarket.com

AutoRig Proは作者によるアドオンの更新も頻繁で、今では動作の安定性を含めて、当初は問題だった不具合がほぼFixされています。

  • 肩や足のリム(関節のチェーン)が捻じれてしまう問題
  • メッシュとボーン(スケルトン)のスケール問題
  • ルートモーション
  • UE4ヒューマノイドリグとの互換性
  • シェイプキーのボーン連携(シェイプキードライバ)
  • 補助ボーンやカスタムボーンの追加

上記の問題のうち、UE4マネキン(グレーマン)の肩から腕のボーンのデフォルト回転と、Autorig Proが生成するFBXとの間で違いが発生してしまうことから、腕がねじれた状態でインポートされてしまう問題にはずいぶん悩まされたのですが、ユーザーが必死で解決法を探っている間に、アドオンそのものが更新されて解決されちゃいましたw

Autorig Proの導入から使用法については、作者によるドキュメント

www.lucky3d.fr

が上記にあります。

英文ですが、図表も動画も豊富にありますので、じっくり読み進めていただければ使用法については網羅できているのかなー、と思います。また、折をみてこのブログでもAutorig Proの使用法を解説できればしようかな、と考えています。

さて…それではBlenderの標準機能だけでキャラクタアセットを作成してUE4で使いたい場合、どのような問題が解消できないのでしょうか。以下は、これを解説します。

Blenderの標準機能だけでは解消できない(か、Fixが難しい)問題点

  • メッシュとアーマチュアのスケール問題(難易度C)
  • ルートボーンに回転が入ってしまう問題(難易度A)
  • UE4ヒューマノイドリグ互換にするのが面倒くさい(難易度D)

f:id:kanianthi:20180610160457p:plain

最初のお約束として、Blenderから標準のFBXエクスポーターでキャラクタ(スケルタルメッシュ)を出力する際、Armatureの名前をデフォルトのままで使用してください。↑のスクショにあるように「茶色の厚揚げ豆腐っぽいオブジェクトアイコン」下の名前欄をデフォルトのままにします。アーマチュアを表す人型アイコンの場所ではありませんので注意しましょう。

なぜなら、UE4でFBXを読み込む際「Armatureという文字列を検索して、こいつがスケルトンなんやで!」と認識しているからです。このお約束を守っていれば、アーマチュアの一番上の階層に「root」ボーンを設置すると、それが正しいrootボーンとして認識され、ルートモーションを使うことができるようになります。

f:id:kanianthi:20180610161150p:plain

f:id:kanianthi:20180610161400p:plain

また、rootボーンは「編集モードで」必ず原点に設置し、すべてのボーンの親になるように作成します。この工程を守ることで、UE4に読み込んだ際にrootボーンの位置情報を「0,0,0」にすることができます。

次に…ここからが超重要です!よく読んで実践して理解してください。

まず、上記のままの「棒状キャラの棒ちゃん」をUE4に読み込んでみます。
すると…

f:id:kanianthi:20180610170051p:plain

↑スケルトン編集画面でrootボーンを選択した状態です。

f:id:kanianthi:20180610170204p:plain

この状態でトランスフォームを見ると…ぎゃー!!!

rootボーンのローカル回転に89.999985(≒90度)の数値ががががが!!!

実はこの状態でも「ゲームキャラとしてアニメーションを動かすだけなら」特に問題はありません。が、しかし…UE4シーケンサーに動きを録画して編集することで、カットシーンなどを作ろうとすると…このroot回転がベイクされてしまい、キャラクタが倒れてしまうのです!

また、このスクショではスケール値も1.1.1で正常に見えますが…実はBlenderでセットアップする際に一手間加えています。
これは、先に紹介したUE4勉強会のスライドでも解説しているのですが…

  1. まず、普通にメッシュにアーマチュアを関連づける(自動ウエイトやアーマチュア変形など)。このとき、アーマチュアもメッシュもすべてのトランスフォームをctrl+aで「適用(mayaでいうフリーズ)」しておくこと。身長160センチのキャラを作るなら、Blenderでも1.6メートル(単位はメートル系で1.0倍)にしておく。後からグズグズいわない!
  2. アレントできたら「オブジェクトモード」でアーマチュアに100倍スケールをかける。XYZすべてに100を入力すれば良い。
  3. 身長100倍に巨大化したキャラクタのアーマチュアにトランスフォーム適用する。スケールは1.0になる。大きさは変わらない。
  4. 再びアーマチュアに0.01倍スケールをかける。キャラクタの大きさが元に戻る。
  5. メッシュのスケール値を確認する。正しく手順を踏んでいれば100が入ったままの状態になっている。
  6. メッシュのスケールを確認したらctrl+aで適用する。スケールが1.0になる。
  7. アーマチュアのスケール値は0.01のまま、FBX出力する。Blender標準のFBXエクスポートの設定は以下の通り。
  8. f:id:kanianthi:20180610171754p:plain

これでいけます。

以上の手順でスケルタルメッシュのスケール問題は解決します…が先のスクショの通り、ルートボーンの角度問題だけは解決策が分かりませんでした…。

しかしついに…

Blenderのrootボーンにデフォルトで角度が入ってしまう問題を解決!

したので紹介します。

f:id:kanianthi:20180610172210p:plain

↑これ。

これじゃわかんねーよ!!!
って言われると思うので解説しますねw

一般論になりますが、リグを考えるときrootはすべてのボーンの親になります。なので、キャラクタの骨格やデフォルトポーズに関係なく、そのアセットの原点として正しく機能する必要があります。逆にいえば、rootボーンを骨格として組み込む必要というのはなくて、ルートモーションを仕込むみたいな「特別な必要性」がない限り、お前はいつもそこにいてじっとしてろよな!って存在なのです。

そこで、rootボーンから接続された骨がない状態をまず作ります。ボーンの編集モードに入り、alt+pで親子関係を解除したり接続解除ができますので、rootを背骨やその他の骨と接続解除し、自由に動ける状態にしておきます。このとき、rootがすべての骨の親である状態は維持する必要があります。

f:id:kanianthi:20180610173111p:plain

↑のスクショで選択状態なのがrootです。
3DマニピュレータのY軸方向を向いているのが分かります。r+xxでローカルX軸回転で「真後ろを向かせた状態」です。ctrlを併用すると角度スナップが効くので簡単です。

これがつまり「UE4にインポートしたときに-90度転んだ状態」なので、先のスクショで見せた「90度転んだ角度でインポートされてしまう」問題を相殺するのです。

ただし…

f:id:kanianthi:20180610173453p:plain

rootボーンのロール角を「必ず0」にしておくことも忘れないでください。ここになにか値が入っているとうまいことUE4にインポートできません。

これらの手順を踏んで正しくFBX出力し…UE4にインポートすると…

f:id:kanianthi:20180610173833p:plain

f:id:kanianthi:20180610173851p:plain

やったー!!!

これでBlenderで作ったキャラクタを正しいトランスフォームでUE4にインポートすることができました!これならシーケンサーでアニメーションをベイクしても問題が起きることはありません!

以上、今回の記事はけっこう大事なことを検証しましたのでお役立てください!

 

 

2018年版:Blenderで作ったキャラクタをUE4にインポートして動かす! Part1

こんにちは、なんです。
前回の投稿から余裕で1年を超えてしまいましたが、その間に個人的に業務的にも恐ろしいほど変化がありました。2017年はCG関係以外の実務やイベント運営などに追われ、ほとんどCG制作に関わることができませんでしたが、年末ごろから徐々にCGリハビリを行い、明けて2018年の初春である現在では、再び新たなノウハウを蓄積しましたのでそろそろ放出しようと思います。

記事の本題に入る前に、この記事のテーマについてお話します。

  1. Blenderで作成した人型キャラクタにアーマチュア(ボーン)を入れ、リグを作成してFBXでエクスポートする。
  2. 上記FBXをUnrealEngine4(4.18.3)にインポートし、UE4マネキンのスケルトンに直接スキンとして「被せる」方法と、別スケルトンとしてインポートし、Mixamoなどのアニメーションアセットをリターゲットする方法の二つを紹介する。
  3. 以上に関わる周辺の様々なTipsやノウハウを提供する。

なお、本稿の作成時点での各ソフトウエアは、Blenderバージョンは2.79a RC、アンリアルエンジンはUE4.18.3での検証を前提にしています。

 

 最初に:BlenderUE4の単位(ユニット)スケール問題

f:id:kanianthi:20180226134940p:plain

↑の画像はBlenderでオリジナルキャラクタ「エビフライ」とアーマチュアを表示しています。3Dビューの右側ペインにトランスフォームのアトリビュートが表示されていて、その下には現在の単位に基づく寸法が表示されています。

表示を見るとZ方向の寸法、つまり身長が約1メートルです。また、さらにその右のペインでは現在の単位プリセットが「メートル法」であり、倍率が1.0倍(等倍)であることも表示されています。

以前の記事に書きましたが、UE4(アンリアルエンジン)の1単位はセンチです。しかしBlenderの単位はメートルまたは英単位系なので、Blender単位1のままUE4に持っていくと、そのオブジェクトは1センチとなり1/100の大きさにスケーリングされてしまう、という問題がありました。

そこで以前までは、Blender側でユニット倍率を.01に設定し、無理やり1ユニットが1センチになるようスケーリングを補正して作業していました。
これは非常に不便な話で、ユニット倍率が.01倍であればオブジェクトの寸法は100倍にしておかないとBlender内でのスケーリングがおかしなことになります。

その結果、Zbrushやサブスタンスペインターなどでディティールの追加やPBRテクスチャを作成する作業や、Blender内で物理シミュレーションを行う作業などで、100倍の大きさのオブジェクトを扱うことになり、あれこれと不具合が生じていたのです。

f:id:kanianthi:20180226140257p:plain

しかし現在のBlenderUE4のワークフローでは、この問題がついに解決したようです。画像のようにスケーリングオプションは1.0倍のまま、右側の倍率補正ボタンをクリックしておくだけでBlender内で1メートルとして作成したオブジェクトは、UE4内でもそのまま1メートルのオブジェクトとして取り込まれます。

f:id:kanianthi:20180226140909p:plain

↑の画像はエビフライを含めたぼくの自作キャラクタたちをUE4のThirdPersonサンプルにインポートしてレベルに表示したものです。すべてのキャラクタの身長がUE4のユニット設定に合致していることが分かります。カエルが大きすぎるじゃないか!というツッコミがあるかも知れませんが、あくまでキャラとしてのカエルなので小学生程度の身長がありますが許してくださいおねがいします(なぜか謙虚)。

アーマチュアとRIGアセットの問題

Autodesk製の3dsMaxにはBiped(キャラクタースタジオ)とCATという二つのプラグインRIGがあります。MayaだとHumanIKなどがあります。これらはDCC(DigitalContentCreation)ツールが標準で持つボーンとリグ機能とは別個に、独自のボーン(あくまでも骨のこと)やリグ(骨やスキンを制御するための仕組)ですが、BlenderにもRigifyが標準搭載されているほか、いくつかのアドオンRIG構築アセットが存在します。

Blenderに存在するアドオンの場合、ボーンやアーマチュア(骨全体を統合した単位)はBlender組み込みのものをそのまま利用し、制御や変形補完、自動バインドといったリグ本来の機能を自動化してくれるアセットになっています。

特にその中でもイチオシなのが

Auto-Rig Pro - Blender MarketAuto-Rig Pro - Blender Marke

blendermarket.com

という有償アドオンです。
40ドルほどしますが、他のDCCのプラグイン・リグで100ドル以下というのはほぼ見たことがありませんので素晴らしい価格設定です。また、機能的にも大変すぐれているので多少余計なこともしてくれますが余裕で笑って導入できるレベルです。

AutoRigProは、半自動でメッシュにボーンをマッピングしてくれるだとか、Mixamoや他のモーションキャプチャファイルからのアニメーションリマッピング、独自のFBXエクスポート機能などを備えています。

また、Rigifyより後発であるため、UnityとUE4に対応したエクスポートプロファイルや最適化されたFBX出力プロファイルを利用できるなど、Blenderゲームエンジンをつなぐワークフローに特化した機能が搭載されています。

ここまで持ち上げといてアレですがwこのアドオンは100倍スケールを自動で付加するオプションを独自のFBXエクスポーターに備えています。とはいえ検証したところ、Blender内でオブジェクトを100倍にするとかUE4でボーンの回転角度や移動量が1/100になってしまうという問題は起きていません。

なんとなくモニョりはしますがAutoRigProからFBXをエクスポートする際には、100倍スケールオプションをオンにしておくと、標準FBXエクスポートの倍率オプションと同様に「BlenderでもUE4でも1メートルのものは1メートル」で作業できますので良しとしておきましょう。

 

以上、今回は本題に入る前のお膳立てについて書きました。
次回はいよいよ、アンリアル・マネキン・スケルトンとBlenderのアーマチュアを互換させるTipsについて書いていきます。