修正版！2018年編：Blenderで作った3DアセットをUE4で利用するためのTipsあれこれ
前回記事から結局少し時間がかかってしまいました。
その間に、新潟県妙高市から引っ越して現在は大阪市のIndie-us Games所属アーティストになったりとか、公私の両面で大きな動きがありました。
この記事を書いている今日（2018年6月10日）から見て、一週間さかのぼると…
UE4のアーティスト向け勉強会が大阪なんばで開催され、そこで登壇させていただきました。当日は技術論やTipsには重きを置かず、アーティストとしてのモノの見方や人生経験などをベースに、若いUE4アーティストやエンジニアの皆さんに、ぼくというアーティストのプロフィールを知っていただき、考えていることや目指していることを伝えることから「IP（知的財産権）を立ててコンテンツを作ること」についてお話しさせていただきました。
スライドの内容については割愛しますが、ブログではあらためて
BlenderとUE4の連携で、問題ってなにがあるの？
について、あらためて紹介し、その対策などを書きたいと思います。
さて、いきなり結論ですが…少なくともBlender2.79b（最新安定版）でキャラクターをモデリングしてFBXに書き出し、UE4でアセット化するにあたって…
ほぼすべての問題が解決しています！
と、もう言っていいんじゃないかなー、と思います。
ただし、無条件にBlender最新版を利用すればすべての問題をなくせるわけではありません。前回の記事でも紹介した「Autorig Pro」の導入は必須と言えます。
AutoRig Proは作者によるアドオンの更新も頻繁で、今では動作の安定性を含めて、当初は問題だった不具合がほぼFixされています。
- 肩や足のリム（関節のチェーン）が捻じれてしまう問題
- メッシュとボーン（スケルトン）のスケール問題
- ルートモーション
- UE4ヒューマノイドリグとの互換性
- シェイプキーのボーン連携（シェイプキードライバ）
- 補助ボーンやカスタムボーンの追加
上記の問題のうち、UE4マネキン（グレーマン）の肩から腕のボーンのデフォルト回転と、Autorig Proが生成するFBXとの間で違いが発生してしまうことから、腕がねじれた状態でインポートされてしまう問題にはずいぶん悩まされたのですが、ユーザーが必死で解決法を探っている間に、アドオンそのものが更新されて解決されちゃいましたｗ
Autorig Proの導入から使用法については、作者によるドキュメント
が上記にあります。
英文ですが、図表も動画も豊富にありますので、じっくり読み進めていただければ使用法については網羅できているのかなー、と思います。また、折をみてこのブログでもAutorig Proの使用法を解説できればしようかな、と考えています。
さて…それではBlenderの標準機能だけでキャラクタアセットを作成してUE4で使いたい場合、どのような問題が解消できないのでしょうか。以下は、これを解説します。
Blenderの標準機能だけでは解消できない（か、Fixが難しい）問題点
最初のお約束として、Blenderから標準のFBXエクスポーターでキャラクタ（スケルタルメッシュ）を出力する際、Armatureの名前をデフォルトのままで使用してください。↑のスクショにあるように「茶色の厚揚げ豆腐っぽいオブジェクトアイコン」下の名前欄をデフォルトのままにします。アーマチュアを表す人型アイコンの場所ではありませんので注意しましょう。
なぜなら、UE4でFBXを読み込む際「Armatureという文字列を検索して、こいつがスケルトンなんやで！」と認識しているからです。このお約束を守っていれば、アーマチュアの一番上の階層に「root」ボーンを設置すると、それが正しいrootボーンとして認識され、ルートモーションを使うことができるようになります。
また、rootボーンは「編集モードで」必ず原点に設置し、すべてのボーンの親になるように作成します。この工程を守ることで、UE4に読み込んだ際にrootボーンの位置情報を「0,0,0」にすることができます。
次に…ここからが超重要です！よく読んで実践して理解してください。
まず、上記のままの「棒状キャラの棒ちゃん」をUE4に読み込んでみます。
すると…
↑スケルトン編集画面でrootボーンを選択した状態です。
この状態でトランスフォームを見ると…ぎゃー！！！
rootボーンのローカル回転に89.999985（≒90度）の数値ががががが！！！
実はこの状態でも「ゲームキャラとしてアニメーションを動かすだけなら」特に問題はありません。が、しかし…UE4のシーケンサーに動きを録画して編集することで、カットシーンなどを作ろうとすると…このroot回転がベイクされてしまい、キャラクタが倒れてしまうのです！
また、このスクショではスケール値も1.1.1で正常に見えますが…実はBlenderでセットアップする際に一手間加えています。
これは、先に紹介したUE4勉強会のスライドでも解説しているのですが…
- まず、普通にメッシュにアーマチュアを関連づける（自動ウエイトやアーマチュア変形など）。このとき、アーマチュアもメッシュもすべてのトランスフォームをctrl+aで「適用（mayaでいうフリーズ）」しておくこと。身長160センチのキャラを作るなら、Blenderでも1.6メートル（単位はメートル系で1.0倍）にしておく。後からグズグズいわない！
- ペアレントできたら「オブジェクトモード」でアーマチュアに100倍スケールをかける。XYZすべてに100を入力すれば良い。
- 身長100倍に巨大化したキャラクタのアーマチュアにトランスフォーム適用する。スケールは1.0になる。大きさは変わらない。
- 再びアーマチュアに0.01倍スケールをかける。キャラクタの大きさが元に戻る。
- メッシュのスケール値を確認する。正しく手順を踏んでいれば100が入ったままの状態になっている。
- メッシュのスケールを確認したらctrl+aで適用する。スケールが1.0になる。
- アーマチュアのスケール値は0.01のまま、FBX出力する。Blender標準のFBXエクスポートの設定は以下の通り。
-
これでいけます。
以上の手順でスケルタルメッシュのスケール問題は解決します…が先のスクショの通り、ルートボーンの角度問題だけは解決策が分かりませんでした…。
しかしついに…
Blenderのrootボーンにデフォルトで角度が入ってしまう問題を解決！
したので紹介します。
↑これ。
これじゃわかんねーよ！！！
って言われると思うので解説しますねｗ
一般論になりますが、リグを考えるときrootはすべてのボーンの親になります。なので、キャラクタの骨格やデフォルトポーズに関係なく、そのアセットの原点として正しく機能する必要があります。逆にいえば、rootボーンを骨格として組み込む必要というのはなくて、ルートモーションを仕込むみたいな「特別な必要性」がない限り、お前はいつもそこにいてじっとしてろよな！って存在なのです。
そこで、rootボーンから接続された骨がない状態をまず作ります。ボーンの編集モードに入り、alt+pで親子関係を解除したり接続解除ができますので、rootを背骨やその他の骨と接続解除し、自由に動ける状態にしておきます。このとき、rootがすべての骨の親である状態は維持する必要があります。
↑のスクショで選択状態なのがrootです。
3DマニピュレータのY軸方向を向いているのが分かります。r+xxでローカルX軸回転で「真後ろを向かせた状態」です。ctrlを併用すると角度スナップが効くので簡単です。
これがつまり「UE4にインポートしたときに-90度転んだ状態」なので、先のスクショで見せた「90度転んだ角度でインポートされてしまう」問題を相殺するのです。
ただし…
rootボーンのロール角を「必ず0」にしておくことも忘れないでください。ここになにか値が入っているとうまいことUE4にインポートできません。
これらの手順を踏んで正しくFBX出力し…UE4にインポートすると…
やったー！！！
これでBlenderで作ったキャラクタを正しいトランスフォームでUE4にインポートすることができました！これならシーケンサーでアニメーションをベイクしても問題が起きることはありません！
以上、今回の記事はけっこう大事なことを検証しましたのでお役立てください！
2018年版：Blenderで作ったキャラクタをUE4にインポートして動かす！ Part1
こんにちは、なんです。
前回の投稿から余裕で1年を超えてしまいましたが、その間に個人的に業務的にも恐ろしいほど変化がありました。2017年はCG関係以外の実務やイベント運営などに追われ、ほとんどCG制作に関わることができませんでしたが、年末ごろから徐々にCGリハビリを行い、明けて2018年の初春である現在では、再び新たなノウハウを蓄積しましたのでそろそろ放出しようと思います。
記事の本題に入る前に、この記事のテーマについてお話します。
- Blenderで作成した人型キャラクタにアーマチュア（ボーン）を入れ、リグを作成してFBXでエクスポートする。
- 上記FBXをUnrealEngine４（4.18.3）にインポートし、UE4マネキンのスケルトンに直接スキンとして「被せる」方法と、別スケルトンとしてインポートし、Mixamoなどのアニメーションアセットをリターゲットする方法の二つを紹介する。
- 以上に関わる周辺の様々なTipsやノウハウを提供する。
なお、本稿の作成時点での各ソフトウエアは、Blenderバージョンは2.79a RC、アンリアルエンジンはUE4.18.3での検証を前提にしています。
最初に：BlenderとUE4の単位（ユニット）スケール問題
↑の画像はBlenderでオリジナルキャラクタ「エビフライ」とアーマチュアを表示しています。3Dビューの右側ペインにトランスフォームのアトリビュートが表示されていて、その下には現在の単位に基づく寸法が表示されています。
表示を見るとZ方向の寸法、つまり身長が約1メートルです。また、さらにその右のペインでは現在の単位プリセットが「メートル法」であり、倍率が1.0倍（等倍）であることも表示されています。
以前の記事に書きましたが、UE4（アンリアルエンジン）の1単位はセンチです。しかしBlenderの単位はメートルまたは英単位系なので、Blender単位１のままUE4に持っていくと、そのオブジェクトは１センチとなり1/100の大きさにスケーリングされてしまう、という問題がありました。
そこで以前までは、Blender側でユニット倍率を.01に設定し、無理やり１ユニットが１センチになるようスケーリングを補正して作業していました。
これは非常に不便な話で、ユニット倍率が.01倍であればオブジェクトの寸法は１００倍にしておかないとBlender内でのスケーリングがおかしなことになります。
その結果、Zbrushやサブスタンスペインターなどでディティールの追加やPBRテクスチャを作成する作業や、Blender内で物理シミュレーションを行う作業などで、100倍の大きさのオブジェクトを扱うことになり、あれこれと不具合が生じていたのです。
しかし現在のBlender→UE4のワークフローでは、この問題がついに解決したようです。画像のようにスケーリングオプションは1.0倍のまま、右側の倍率補正ボタンをクリックしておくだけでBlender内で1メートルとして作成したオブジェクトは、UE4内でもそのまま1メートルのオブジェクトとして取り込まれます。
↑の画像はエビフライを含めたぼくの自作キャラクタたちを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
という有償アドオンです。
40ドルほどしますが、他のDCCのプラグイン・リグで100ドル以下というのはほぼ見たことがありませんので素晴らしい価格設定です。また、機能的にも大変すぐれているので多少余計なこともしてくれますが余裕で笑って導入できるレベルです。
AutoRigProは、半自動でメッシュにボーンをマッピングしてくれるだとか、Mixamoや他のモーションキャプチャファイルからのアニメーションリマッピング、独自のFBXエクスポート機能などを備えています。
また、Rigifyより後発であるため、UnityとUE4に対応したエクスポートプロファイルや最適化されたFBX出力プロファイルを利用できるなど、Blenderとゲームエンジンをつなぐワークフローに特化した機能が搭載されています。
ここまで持ち上げといてアレですがｗこのアドオンは100倍スケールを自動で付加するオプションを独自のFBXエクスポーターに備えています。とはいえ検証したところ、Blender内でオブジェクトを100倍にするとかUE4でボーンの回転角度や移動量が1/100になってしまうという問題は起きていません。
なんとなくモニョりはしますがAutoRigProからFBXをエクスポートする際には、100倍スケールオプションをオンにしておくと、標準FBXエクスポートの倍率オプションと同様に「BlenderでもUE4でも1メートルのものは1メートル」で作業できますので良しとしておきましょう。
以上、今回は本題に入る前のお膳立てについて書きました。
次回はいよいよ、アンリアル・マネキン・スケルトンとBlenderのアーマチュアを互換させるTipsについて書いていきます。
3D CGテクスチャリングを2歩か3歩進めたい！ 4：シェーディングの基礎と色の話V2
ちょっと前回から間が開きましたが、これが通常運行という感じでしょうね。
今回の内容はけっこう重要です。いつも重要なことを書いているつもりではいますがｗさらに本気で重要なことです。
ソフトウエアのターゲットはBlenderということになっていますが、あらゆるCG制作において大事なことをお話ししたいと思います。
白い、黒い、とはどういうことか
↑各種のペイントソフトウエアなどでよくあるグラデーション指定のダイアグラムなどにあるアレですね。しかしこの図、実は非常に重大な事実を教えてくれます。
一般に、日常生活レベルで「白い」とか「黒い」というとき、それは「肉眼で見た色」のことを指しています。白黒に限った話ではなく、赤い、とか青い、というのも同じく目で見た（見える）色の話です。そして、我々が目で見ている「色」というものは、実は相対的な指標にすぎず、照明や背景によっていくらでも変化してしまいます。
紙に絵の具などで絵を描くとき、絵を少しでも学んだことのあるひとであれば「紙の地色である白」をその絵の中で「最も明るい色」とすることを知っていると思います。しかしその紙の地色さえも、赤みを帯びたライトを浴びたり、薄暗い照明の下では「白」に見えないことも、簡単に想像ができますよね。
このように、私たちが視覚として見ている色というものは、相対的なものです。しかし、デジタルデータであるCGは、2Dであろうと3Dであろうと「絶対値としての色」をピクセルデータとしてメモリに「書き込んで」いるのです。
絶対的カラー
webデザインでHTMLをコーディングしたことがあれば、白をFFFFと表記することをご存じでしょう。
あるいは印刷について詳しいひとであれば、キンアカと呼ばれる標準的な赤い色を「M100% Y100%」で指定することを知っているでしょうし、DICやパントンのカラーチップを用いて、特色を「絶対値」として指定できることも分かるでしょう。
同じように、コンピューターを使った視覚表現（グラフィックス）は、ピクセルごとに絶対値で表現されます。したがって「白より白い白」などという、歯磨き粉や洗剤で使われそうなコピーは通用しません。
RGBがそれぞれ100%混ざった（加色混合された）結果は白で、これ以上明るい色はデジタルデータにはありません。同じように、RGBがそれぞれ0%であれば、それ以上暗い色もデジタルデータでは存在しないのです。
↑画像は以前ぼくが作成した、とあるゲームのMOD用レザースーツの編集画面です。
Blenderのビューポート画面なので雰囲気しか伝わらないと思いますが、これは「黒い革製の光沢があるワンピース」をイメージしていました。
↑こちらはその革スーツ用の拡散反射光テクスチャ（ディフューズカラー）です。黒いスーツをデザインしたので当然「暗い色」で彩色されていますが、背景の「100%ブラック」よりはすべて明るい色で描かれています。
これはなにを意味するのでしょう？
「黒いスーツなのに黒く塗らない」その意味とは？
なぜなら、たとえ黒い（と印象づけられている）服であっても、陰影があるはずです。最初からRGB0%の絶対ブラックで塗られていたなら、皺の谷間などにできる影の部分が表現できません。
もちろん「物理的に正しい」とされるPBRな光を浴びれば、たとえテクスチャが絶対ブラックで描かれていても、レンダリング結果としては多少明るくなるし、材質の設定によってハイライトも描かれるでしょう…
↑は同じアセットの色味を吟味するために、設定を少しずつ変えてレンダリングしたものです。左上の設定くらいのモデルで、背景があり人物がそれを着ていたなら、十分に「黒い革のスーツ」に見えると思います。
しかし、この素材のテクスチャはベースカラーとして20%くらいの「濃いグレー」で描かれており、フォトショップでの合成で「凹凸に応じた陰影」を多少乗算されている程度です。
白はさらに難しい
SubstancePainterなどのPBRレンダラー用テクスチャリングツールでマテリアルを作成しているとよく遭遇するのですが、うっかりカラースライダを「真っ白」まで上げてしまうと、マテリアルが表現すべきハイライトが喪失し、なんだか変な状態になります。
一般に黒い服は比較的描けるようでも、白い服を描くのは難しいものです。
白なのに光沢がある質感…これをありありと絵として表現できるイラストレーターは、そこそこのテクニックを持っている、と言えるでしょう。
しかしぼくが知る限り、多くの入門者さんは「この服は白だから白」とマテリアルやテクスチャを作成してしまいます。RGB100%の白より明るい色は、先に書いたようにデジタルでは表現しようがありませんので、影を落とすことはできてもハイライトのない、野暮ったい服になってしまいます。
とりあえず簡単なレベルアップ法としては、白も黒もスライダをがっつり上げたくなるのをグっと堪えて、80%か85%くらいの範囲でとどめておけば、それより明るいハイライトやシャドウがちゃんと乗るようになります。
特にUE4などのプリレンダリングで陰影（シェーディング）を焼き込んでおくレンダラーや、セルアニメ系レンダリングではハイライトやシャドウのない、野暮ったくて貧弱なレンダリング結果しか得られなくなりがちなので気をつけましょう。
なにはともあれ、デザインだとかアートの分野では、なにか特別な理由がない限り100%ホワイトや0%ブラックは「使わない」と覚えておくことが、作品を二歩か三歩レベルアップさせるためのポイントです。
では、今回はここまで！
3D CGテクスチャリングを2歩か3歩進めたい！ 3：シェーディングの基礎と色の話
前回まではUV展開の考え方について書きました。
話を進めるうちに、またUVについては触れなければならなくなると思いますが、いったんそこは離れて、今回はテクスチャリングの中心にある色とシェーディングの解説をしたいと思います。
標準ノーマルカメラ
↑のようにシンプルなシーンをBlenderで設定しました。
単純に、90度回転して立たせた平面ポリゴンとカメラがあるだけです。カメラは真っすぐ垂直に平面を向いています。対象物に対してノーマル方向に設置してあるのでノーマルカメラと言います。
このとき、光源（ライト）も平面に対して鉛直な平行光源（サンなど）を設置したとすると、レンダリング結果はどうなるでしょうか？
え？マテリアルを設定しないとなにもレンダリングされない？ｗｗ
いやいやｗｗそんなとんちをしたいわけではなくてですねｗｗ
この場合、レンダリングした結果は、マテリアルもしくはテクスチャが「そのまんま表示される」はずなのです。この「そのまんま」というのは「いっさい陰影がない状態」という意味になります。
↑シーンを真横から見たものです。
（原点に置いて置くと平面が見えなくなるのでｗズラしました。）
すべてが正対している状態では、物体を照らす光と反射して返ってくる光の方向が一致します。これは「光の減衰が最も起こらない状態」であり、陰影（シェーディング）が発生しない状態なのです。
シェーディングの基礎
↑を見てください。
平面から面を押し出し、角度をつけてみました。ビューポートに陰影が発生しているのが分かると思います。
↑真上から見た図です。
Aはもともとの平面、BとCは追加した曲がっている平面です。
上から見るとはっきり分かる通り、Aの面に入射した光はそのまま真っすぐに反射されるので１：１の比率でカメラに戻ります。しかし、BとCの面については傾きがあるので、光は真っすぐ返ることができません。
BもしくはCの傾きが0度、すなわち平行であるときは１：１ですが、傾きの角度がきつくなるにつれて反射光は少なくなり、90度に達したときに０になります。
実際にレンダリングしてみましょう。
↑分かりやすくするために床を追加し「影」を落としました。確かに、傾きをつけた両サイドの面が「暗く」なっています。これは、「入射した光に対して返ってきた光が少ない」から起きた現象です。
グラデーションの誕生
さらに一歩進めて、平面をこんな風に加工します。
↑はい、両サイドの傾き面を分割し、角度をオフセットしました。その結果は…
当然こうなりますよね。
真ん中の平行面に対して、両端の面はそれぞれの傾き角度に応じて反射光が少なくなるので減衰し、暗くなります。
それではさらに…
一気にベベルで角を増やしました。全体的に「丸く」なりましたね。
レンダリングすると↑になります。
このように、傾きを細分化して分割数を増やしていくとそれだけ反射光の減衰も滑らかになっていきます。やがて円柱になるまで面を分割してしまうと、反射光の減衰はグラデーションになることが理解できると思います。
逆に考えると、フォトショップなどで「円柱グラデーション」を使って長方形に色を塗ると、なんと！なぜか円柱に見えてしまう理由がこれです。
さて、今回はここまでにします。
次回は「白と黒の秘密」についてです。
3D CGテクスチャリングを2歩か3歩進めたい！ 2：続UVの考え方編
前回に引き続きUVの考え方について書きます。
3D CGであっても、リアルの工作であっても、三次元の立体物を二次元に投影して展開すると、必ず上下が反転したり左右がおかしくなるので、2D投影したときに「描きやすい」ようにUVをレイアウトすることが大事、と前回はまとめました。
今回はそこから一歩進んで、同じ立方体でも「二つの捉え方（考え方）」があることを説明したいと思います。
立方体の二つの捉え方
A：それぞれが独立した面
↑がその概念図になります。
立方体を連続面と捉えず「それぞれ90度のアングルで貼り合わせた6面体」と考えるわけです。割と多くのメカニックや乗り物、家や建築物はこの方法で捉え、UV展開することが多くなります。
この方法のメリットは、それぞれの面を的確に平行投影できることです。原理的にUVのゆがみは発生しません。逆に、デメリットはUVの継ぎ目が増えるのでレンダリングしたときにも継ぎ目が見えてしまったり、連続面を意識したテクスチャリングがしにくくなることです。
これはBlenderでいうところの「スマートUV展開」の考え方でもあります。
立方体の場合なら90度未満の角度を指定してスマートUV展開を行えば、画像とまったく同じ捉え方で自動でUVが展開されます。ただし、各面の上下左右がどうなっているかまでは、UVレイアウトで頂点を選択してみるなどして3Dビューと照らし合わせで確認しなければなりません。
3Dペイントをすぐに行うのであればいらない手間ですが、あとでデカールをフォトショップで貼りたいなどというときにはUV面がビューポートで上下左右どちらを向いているのかを調べておいても損はないでしょう。
B：蓋と筒で捉える
↑同じく概念を画像にしました。
立方体なので少々でこぼこがきついですが、上下に蓋のついた筒、と形状を捉えます。この方法で展開したUVは「単独面である蓋が2枚と連続面である筒部分」という3つのUV島（アイランド）がリザルトとして出来上がります。
また、一度この方法で3枚の島を作成してから蓋2枚を筒部分にスティッチ（貼合わせ）すれば、デフォルトUVと同じ「サイコロの展開図」が出来上がることも理解できるかと思います。
この方法のメリットは、UVの継ぎ目（シーム）が最小限であることです。また、連続面が作れますので、立方体を回転させてもつなぎ目の分からない「シームレスなテクスチャ」を描くことが可能になります。
逆にデメリットとしては連続面なので各面を厳密に色分けしたいケースなどには向かないこと、上下左右を考えたテクスチャリングを行わなければならないことなどです。
なにはともあれ、AとBの二つの捉え方で大抵の立体物をUV展開することが可能です。
↑こんな風に4隅にベベルをかけて丸みをつけても「蓋と筒」であることに変わりはありません。
同じく…
↑なんのことはない、円筒も「蓋と筒」の方法で簡単にUV展開ができます。
最後の難敵→球体
↑はBlenderで「UVを生成」をオンにしてUV球を作成し、編集モードでUVレイアウトを確認したところです。
立方体だと見事なサイコロ展開図だったのに比べ、いかにも「ひどい感」がするUVですね。いくら自動生成とはいえ、これはない！とぼくも思います。
しかしながら、数学とか幾何の授業で習ったことはないでしょうか…「球体を二次元に歪みなく完全に投影することは不可能」なのです。
地球儀で見られるメルカトール法などが、かなり「頑張ったやり方」ではありますが、それにしても軸付近で必ず歪みはできてしまいます。どんどんメルカトール分割を増やしていけば「近似値としての球体」には近づいていきますが、完全球にはなりません。
とはいえ…
↑3D CGで一般的な球のUV展開はこれです。赤道面にシームを一本入れて、上下に分割して投影するわけです。
眼球のように、極部分のテクスチャさえ正確に描ければ良いのであれば、この方法で間違いなくテクスチャペイントが可能です。しかし、どうしても赤道面（分割面）に近づけば近づくほど歪みは出てしまいます。
そこで
このようにシームを一本、赤道から極に向かって引きます。
すると当然、円錐の平面展開のような図形が出来上がりますが、UV面の歪みは小さくなります。ただし、眼球のようなテクスチャをペイントするには向きません。
この方法は、たとえば丸っこい靴のつま先や、指先などのようにカプセル形状に似た端っこのUV展開を行う際に良くあるやり方です。キャラクタでは顔面のUVを展開するときにも、髪に隠れる額の部分や、顎の下などに「切れ目」を入れて歪みのないUVを作成しようとします。
3D CGモデリングでは「球面（半球）に近似している形状」は良く出てきます。その時々に応じて、赤道面だけのシームで良いのか、切れ目も入れて歪みを少なくすべきか考えてUV展開を行うことが求められます。
さて、今回でUV三人衆を片付けることが出来ました。
次回は、シェーディングの基礎の基礎を交えて、より実践的なテクスチャリングについて説明したいと思います。
3D CGテクスチャリングを2歩か3歩進めたい！ 1：UVの考え方編
今回から3D CGに必須のテクスチャリングについて少し書きます。
例のごとくBlenderを対象アプリケーションにしていますが、どんな3Dソフトでもまったく同じ考え方が通用します。基礎の基礎をきちんと理解して、その応用として高度なテクスチャリングを作れる「入口」に到達していただくのが目的です。
よくある解説では、UV展開のやり方そのものをソフトウエアの機能をベースに解説しています。なぜUVが必要か？はともかく、どういうUVが良いの？という部分がすっぽり抜けていて、いきなりシーム引いて展開コマンド入れるとほらできた！みたいな記事になっていることが多く、それでは機能解説に過ぎないのです。
今回のお題
↑Blenderのシーンに現れたUV3人衆です。
とりあえずこいつらのUVを「きちんと開ける」ようになることが最初のステップです。多少複雑なモデルやキャラクタになったとしても、この３つを的確にUV展開できるようになっていればあとはその応用に過ぎません。
最初の敵：立方体は一番面倒
立方体というかサイコロ…こいつがですね、なかなかどうして難敵です。ハードサーフェースモデリングでも出てくる問題がいきなり発生します。
↑ちなみにBlenderに最近備わったのがコレ。
デフォルトでプリミティブにUVをつけてくれます。なんだいきなり解決じゃない！って？そんなわけありませんｗ
UVの展開法ではなく、展開するための考え方を説明するために、敢えて自動生成したUVで「あー面倒くせー！」って状況を実感していただくことが目的です。
さて…こうやってUVを自動生成した立方体に、いきなりテクスチャリングをしてみましょう。TABキーなどでテクスチャペイントモードを選択するだけです。
すると↑の画面になるはずです。
立方体がマゼンタ色に見えているのは、まだマテリアルもテクスチャも設定（生成）されていないからです。
そこで、ペイントスロットを追加します。Blenderには上記のペイントスロットが備わっていて、なにげにいろんなテクスチャを塗れます。PBR時代の今では若干古臭いスロットもあるにはありますが、かなり高機能ですね。
今回はディフューズ色を作成します。ブランクテクスチャが生成されて、立方体が真っ黒になれば正解です。続いて画面下のペインをUV/画像エディターにしましょう。
↑今回はBlenderのペイント機能を解説したいわけではないので、ちゃちゃっとマウスで「あいうえお か」を書きました。立方体なので6面あります。UVエディタには、まさに「サイコロの展開図」が表示されています。
さていきなり分かることは…文字の向きが「えかいお」と「あ う」で上下が逆転していることですね。これは現実に立方体を展開してみてもまったく同じ問題に遭遇します。UV展開ができた！よし塗るぞ！とフォトショップなどでテクスチャを描いてみたら…上下があちこちでおかしくなってしまった！なんて状況は、以前よくありましたｗ
ただし最近では、どんな風にUVを展開していたとしても、Blenderのペイント機能やフォトショップの3Dペイント、Zbrushなどを利用してサンジゲンのオブジェクトに直接ペイントすることが可能になりましたので、随分と楽です。
UVの考え方、そのいち
というわけで、今ほど体験した通りです。UV展開したー！よし塗るぞー！あれ？上下違うじゃねーか！！というのは、かなりよくあるお話しです。しかしこれは、UVに特有の問題なわけではありません。
立体物を二次元に投影/展開すると必ず起きる問題
なのです。
そこで、今のように3Dペインティングが普及していなかった時代にはUVレイアウトを画像として出力し、それをテンプレに2Dソフトでテクスチャリングしていたので…
↑のように、すべてのUVアイランドでテクスチャの方向が一致するようにすべてYアップにしておいたりなど、テクスチャを2Dの状態で描きやすいように配置するなどの工夫がありました。
現在でも、3Dペインティングの修正や補正にフォトショップなどの2Dワークフローを利用することはよくあります。そのときに「2DペイントしやすいUV」だったら、修正作業もとても楽になります。
このようにUV展開では、その後の作業を見据えた、テクスチャリングを楽にする展開と配置が大事になりますよ！というところで今回はここまで。
次回もUVの実践的な考え方について進めていきます。
ZBとBlenderでUE4用のキャラを作る #10：Blenderキャラに物理で動く揺れモノを！
番外編で「予想していたトラブルに遭遇したけどなぜか外出して帰ったら勝手に解決した！」経緯を書きました。というわけで、ぼくが番外編で書いたように「物理をオンにしたらボーンがひっくり返ったよ！？」みたいな状況に陥ったら「PCごと再起動」してみてください。昔から続く万能の「おまじない」です。
ソースのご紹介
最初に、今回の記事を作成するにあたり、参考にさせていただいたソースを紹介いたします。
特にalwei（Twitter id @aizen76）さんにはいくつか質問もさせていただきました。ありがとうございました。
ワサビミドリさんの骨
↑画像で示した通り、すでにワサビミドリさんにはモーションがつき、FBX6.1ASCIIでエクスポートも終わっています。この、オサゲ左右に今回はAnimDynamicsノードを利用して簡易物理シミュをつけたいと思います。
もともとUE4内で揺らすつもりだったので、オサゲや前髪に骨は入れましたがモーションはつけていません。なお、もともとはアーマチュアモディファイヤの下に「修正スムーズ（Corrective Smooth）モディファイヤを付けて変形補正をしていたのですが、どうやらUE4では修正スムーズの結果が反映されないようですので、現在のシーンファイルでは外しています。
そのため、若干変形補正用のコンストレインツの付け方やパラメータにも変更を加えました。この辺はサンプルファイルを完成品と捉えず、皆さんで研究していただけたら、と思います。
UE4での基本セットアップ
すでにFBXは用意してありますので…
- UE4へのスケルタルメッシュインポート
- ThirdPersonAnimBPのリターゲット
- 各アニメーションの更新
- マテリアルの作成
などの基本的な作業は「すたちゅーさん導入記事」と同様です。
ここではそれ以降の部分を解説します。
AnimDynamicsノードをアニメーションブループリントに付け足す
↑では同じ「アニムダイナミクス」ノードが二つ並んでいますが、上が左のおさげ用で下が右のおさげ用です。パラメータについても左右が反転しているだけで同じものです。また、こうしたノードの複製はコピペでもいけますので便利です。
また、画像は「walk/Run」ステートになっていますが、AnimDynamicsは、おそらくアニムグラフそのものにもつけられそうですがまだ試していません。とりあえず実験、という意味で、単一ステートではもっとも動きに変化のあるwalk/Runで作業してみました。というか…
言ってるそばから、どうせなら修正しておきましょう！とアニムグラフそのものにAnimDynamicsさせる修正を行いました。重複するのでwalk/Runステート内のノードは削除しておきます。
続いて、アニムダイナミクスノードを選択すると右ペイン下の詳細パネルに出てくるパラメータを指定します。まずはおさげの根元と先っぽを「チェーン」で指定し、連続した動きになるように設定します。
次に重要なのはBox Extentsという物理シミュ用のダミー立方体の大きさとLocal Joint Offsetによる物理ジョイント位置の補正です。
番外編記事でも書いたように、ワールドの座標系とは違い、ボーンのローカル座標軸は「ロール方向がX」になります。つまりボーン軸から見て前（ノーマル方向）がXです。
UE4で描画されるボーンの位置は、Blenderでセットアップした時と比較して「ボーンひとつ分」後退していることが多くなります。これはUE4でのボーン位置は相対的なモノであって、Blenderでモーションをつけるときに行うメッシュとの関係性とは異なるために生じる問題のようです。
↑つまりこんな感じ。
upperArmボーン（上腕）がどう見ても肩になっちゃっています。しかし動かすと正常に腕が動きます。なぜこんなことに？というと、LeafBoneと呼ばれる終端ボーンがないからなのですが…とりあえずそこは本題と離れるので今回は割愛し、とにかくモデリングしたときとUE4のボーン位置はズレる。でもBlenderで作ったアニメーションを再生するだけなら問題なし！と覚えておけば十分です。
しかし今回のように、物理シミュレーションはUE4内で生成される動きですから、ある程度ボーン位置を補正しておかないと結果がおかしくなり、異常にリグが暴れたりする結果を招くのです。
物理コンストレインツと簡易コリジョン
まず最初に、今回のセットアップでは
- X回転はボーンのロール（ねじれ）
- Ｙ回転は横の揺れ（ヨー）
- Z回転は縦の揺れ（ピッチング）
となることを理解しておきましょう。
物理シミュは楽しいのですが、好き勝手に物理させておくとあり得ない動きになってしまいます。そこでコンストレイントをかけて動きを制限するのですが、どのようにパラメータをつければ狙った動きになるのか、最初にそれぞれの軸回転の「表現」をイメージしておくことがモーションデザインでは重要です。
↑コンストレイント関係はこんな感じです。
Linearは距離でAngularは角度の制限です。それぞれの数値がどう動きになるのかイメージしながら実験し、狙った動きになるまで数値を煮詰めます。おさげがあんまり下に向いて欲しくなければ、正方向の角度制限をきつくすれば良いのではないでしょうか。
最後にPlanar Limitという平面コリジョンを設定します。
今回は胴体（というか胸rib）につけるかと思ったのですが、上腕につけた方が動的な印象が良かったので左右の腕にコリジョンを設定しました。
↑画像の半透明緑色の板キレがPlanarLimitです。
妙な青い矢印状のなにかがついていますが、コリジョンの裏表を表示しています。物理シミュを行うボーンに対して、平面コリジョンが裏側を向いていると結果が暴れるのでPlanar Transformの数値でキャラクタに対して後ろを向くようにコリジョンを設定します。（実は最初これが分からなくて暴れる物理にヤキモキしましたｗ）
以上の設定で呆気なくBlenderで作成したキャラに物理で動く揺れモノが設定できました。数値は作業途中のものですので、サンプルファイルをDLした方は好きなように変更して実験してみてください。
最後にサンプルプロジェクトへのリンクです。
ワサビミドリさんのBlenderファイルとFBXなどはこっち
