当たったらどうすんだよ

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

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

こんにちは、なんです。
この記事は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について書いていきます。

 

 

 

3D CGテクスチャリングを2歩か3歩進めたい! 4:シェーディングの基礎と色の話V2

ちょっと前回から間が開きましたが、これが通常運行という感じでしょうね。
今回の内容はけっこう重要です。いつも重要なことを書いているつもりではいますがwさらに本気で重要なことです。

ソフトウエアのターゲットはBlenderということになっていますが、あらゆるCG制作において大事なことをお話ししたいと思います。

白い、黒い、とはどういうことか

f:id:kanianthi:20160625181310p:plain

↑各種のペイントソフトウエアなどでよくあるグラデーション指定のダイアグラムなどにあるアレですね。しかしこの図、実は非常に重大な事実を教えてくれます。

一般に、日常生活レベルで「白い」とか「黒い」というとき、それは「肉眼で見た色」のことを指しています。白黒に限った話ではなく、赤い、とか青い、というのも同じく目で見た(見える)色の話です。そして、我々が目で見ている「色」というものは、実は相対的な指標にすぎず、照明や背景によっていくらでも変化してしまいます。

紙に絵の具などで絵を描くとき、絵を少しでも学んだことのあるひとであれば「紙の地色である白」をその絵の中で「最も明るい色」とすることを知っていると思います。しかしその紙の地色さえも、赤みを帯びたライトを浴びたり、薄暗い照明の下では「白」に見えないことも、簡単に想像ができますよね。

このように、私たちが視覚として見ている色というものは、相対的なものです。しかし、デジタルデータであるCGは、2Dであろうと3Dであろうと「絶対値としての色」をピクセルデータとしてメモリに「書き込んで」いるのです。

絶対的カラー

webデザインでHTMLをコーディングしたことがあれば、白をFFFFと表記することをご存じでしょう。

あるいは印刷について詳しいひとであれば、キンアカと呼ばれる標準的な赤い色を「M100% Y100%」で指定することを知っているでしょうし、DICやパントンのカラーチップを用いて、特色を「絶対値」として指定できることも分かるでしょう。

同じように、コンピューターを使った視覚表現(グラフィックス)は、ピクセルごとに絶対値で表現されます。したがって「白より白い白」などという、歯磨き粉や洗剤で使われそうなコピーは通用しません。

RGBがそれぞれ100%混ざった(加色混合された)結果は白で、これ以上明るい色はデジタルデータにはありません。同じように、RGBがそれぞれ0%であれば、それ以上暗い色もデジタルデータでは存在しないのです。

f:id:kanianthi:20160625183358p:plain

↑画像は以前ぼくが作成した、とあるゲームのMOD用レザースーツの編集画面です。

Blenderのビューポート画面なので雰囲気しか伝わらないと思いますが、これは「黒い革製の光沢があるワンピース」をイメージしていました。

f:id:kanianthi:20160625183617p:plain

↑こちらはその革スーツ用の拡散反射光テクスチャ(ディフューズカラー)です。黒いスーツをデザインしたので当然「暗い色」で彩色されていますが、背景の「100%ブラック」よりはすべて明るい色で描かれています。

これはなにを意味するのでしょう?

黒いスーツなのに黒く塗らない」その意味とは?

なぜなら、たとえ黒い(と印象づけられている)服であっても、陰影があるはずです。最初からRGB0%の絶対ブラックで塗られていたなら、皺の谷間などにできる影の部分が表現できません。

もちろん「物理的に正しい」とされるPBRな光を浴びれば、たとえテクスチャが絶対ブラックで描かれていても、レンダリング結果としては多少明るくなるし、材質の設定によってハイライトも描かれるでしょう…

f:id:kanianthi:20160625184624j:plain

↑は同じアセットの色味を吟味するために、設定を少しずつ変えてレンダリングしたものです。左上の設定くらいのモデルで、背景があり人物がそれを着ていたなら、十分に「黒い革のスーツ」に見えると思います。

しかし、この素材のテクスチャはベースカラーとして20%くらいの「濃いグレー」で描かれており、フォトショップでの合成で「凹凸に応じた陰影」を多少乗算されている程度です。

白はさらに難しい

SubstancePainterなどのPBRレンダラー用テクスチャリングツールでマテリアルを作成しているとよく遭遇するのですが、うっかりカラースライダを「真っ白」まで上げてしまうと、マテリアルが表現すべきハイライトが喪失し、なんだか変な状態になります。

一般に黒い服は比較的描けるようでも、白い服を描くのは難しいものです。

白なのに光沢がある質感…これをありありと絵として表現できるイラストレーターは、そこそこのテクニックを持っている、と言えるでしょう。

しかしぼくが知る限り、多くの入門者さんは「この服は白だから白」とマテリアルやテクスチャを作成してしまいます。RGB100%の白より明るい色は、先に書いたようにデジタルでは表現しようがありませんので、影を落とすことはできてもハイライトのない、野暮ったい服になってしまいます。

とりあえず簡単なレベルアップ法としては、白も黒もスライダをがっつり上げたくなるのをグっと堪えて、80%か85%くらいの範囲でとどめておけば、それより明るいハイライトやシャドウがちゃんと乗るようになります。

特にUE4などのプリレンダリングで陰影(シェーディング)を焼き込んでおくレンダラーや、セルアニメレンダリングではハイライトやシャドウのない、野暮ったくて貧弱なレンダリング結果しか得られなくなりがちなので気をつけましょう。

なにはともあれ、デザインだとかアートの分野では、なにか特別な理由がない限り100%ホワイトや0%ブラックは「使わない」と覚えておくことが、作品を二歩か三歩レベルアップさせるためのポイントです。

では、今回はここまで!

 

 

 

 

3D CGテクスチャリングを2歩か3歩進めたい! 3:シェーディングの基礎と色の話

前回まではUV展開の考え方について書きました。
話を進めるうちに、またUVについては触れなければならなくなると思いますが、いったんそこは離れて、今回はテクスチャリングの中心にある色とシェーディングの解説をしたいと思います。

標準ノーマルカメラ

f:id:kanianthi:20160621200411j:plain

↑のようにシンプルなシーンをBlenderで設定しました。

単純に、90度回転して立たせた平面ポリゴンとカメラがあるだけです。カメラは真っすぐ垂直に平面を向いています。対象物に対してノーマル方向に設置してあるのでノーマルカメラと言います。

このとき、光源(ライト)も平面に対して鉛直な平行光源(サンなど)を設置したとすると、レンダリング結果はどうなるでしょうか?

え?マテリアルを設定しないとなにもレンダリングされない?ww
いやいやwwそんなとんちをしたいわけではなくてですねww

この場合、レンダリングした結果は、マテリアルもしくはテクスチャが「そのまんま表示される」はずなのです。この「そのまんま」というのは「いっさい陰影がない状態」という意味になります。

f:id:kanianthi:20160621201650j:plain

↑シーンを真横から見たものです。

(原点に置いて置くと平面が見えなくなるのでwズラしました。)

すべてが正対している状態では、物体を照らす光と反射して返ってくる光の方向が一致します。これは「光の減衰が最も起こらない状態」であり、陰影(シェーディング)が発生しない状態なのです。

シェーディングの基礎

f:id:kanianthi:20160621202640j:plain

↑を見てください。

平面から面を押し出し、角度をつけてみました。ビューポートに陰影が発生しているのが分かると思います。

f:id:kanianthi:20160621203031j:plain

↑真上から見た図です。

Aはもともとの平面、BとCは追加した曲がっている平面です。
上から見るとはっきり分かる通り、Aの面に入射した光はそのまま真っすぐに反射されるので1:1の比率でカメラに戻ります。しかし、BとCの面については傾きがあるので、光は真っすぐ返ることができません。

BもしくはCの傾きが0度、すなわち平行であるときは1:1ですが、傾きの角度がきつくなるにつれて反射光は少なくなり、90度に達したときに0になります。

実際にレンダリングしてみましょう。

f:id:kanianthi:20160621204919p:plain

↑分かりやすくするために床を追加し「影」を落としました。確かに、傾きをつけた両サイドの面が「暗く」なっています。これは、「入射した光に対して返ってきた光が少ない」から起きた現象です。

グラデーションの誕生

さらに一歩進めて、平面をこんな風に加工します。

f:id:kanianthi:20160621205659j:plain

↑はい、両サイドの傾き面を分割し、角度をオフセットしました。その結果は…

f:id:kanianthi:20160621205932p:plain

当然こうなりますよね。
真ん中の平行面に対して、両端の面はそれぞれの傾き角度に応じて反射光が少なくなるので減衰し、暗くなります。

それではさらに…

f:id:kanianthi:20160621210642j:plain

一気にベベルで角を増やしました。全体的に「丸く」なりましたね。

f:id:kanianthi:20160621210808p:plain

レンダリングすると↑になります。
このように、傾きを細分化して分割数を増やしていくとそれだけ反射光の減衰も滑らかになっていきます。やがて円柱になるまで面を分割してしまうと、反射光の減衰はグラデーションになることが理解できると思います。

逆に考えると、フォトショップなどで「円柱グラデーション」を使って長方形に色を塗ると、なんと!なぜか円柱に見えてしまう理由がこれです。

さて、今回はここまでにします。

次回は「白と黒の秘密」についてです。

 

 

 

 

 

3D CGテクスチャリングを2歩か3歩進めたい! 2:続UVの考え方編

前回に引き続きUVの考え方について書きます。

3D CGであっても、リアルの工作であっても、三次元の立体物を二次元に投影して展開すると、必ず上下が反転したり左右がおかしくなるので、2D投影したときに「描きやすい」ようにUVをレイアウトすることが大事、と前回はまとめました。

今回はそこから一歩進んで、同じ立方体でも「二つの捉え方(考え方)」があることを説明したいと思います。

立方体の二つの捉え方

f:id:kanianthi:20160619140758j:plain

A:それぞれが独立した面

↑がその概念図になります。

立方体を連続面と捉えず「それぞれ90度のアングルで貼り合わせた6面体」と考えるわけです。割と多くのメカニックや乗り物、家や建築物はこの方法で捉え、UV展開することが多くなります。

この方法のメリットは、それぞれの面を的確に平行投影できることです。原理的にUVのゆがみは発生しません。逆に、デメリットはUVの継ぎ目が増えるのでレンダリングしたときにも継ぎ目が見えてしまったり、連続面を意識したテクスチャリングがしにくくなることです。

これはBlenderでいうところの「スマートUV展開」の考え方でもあります。

立方体の場合なら90度未満の角度を指定してスマートUV展開を行えば、画像とまったく同じ捉え方で自動でUVが展開されます。ただし、各面の上下左右がどうなっているかまでは、UVレイアウトで頂点を選択してみるなどして3Dビューと照らし合わせで確認しなければなりません。

3Dペイントをすぐに行うのであればいらない手間ですが、あとでデカールフォトショップで貼りたいなどというときにはUV面がビューポートで上下左右どちらを向いているのかを調べておいても損はないでしょう。

f:id:kanianthi:20160619142336j:plain

B:蓋と筒で捉える

↑同じく概念を画像にしました。

立方体なので少々でこぼこがきついですが、上下に蓋のついた筒、と形状を捉えます。この方法で展開したUVは「単独面である蓋が2枚と連続面である筒部分」という3つのUV島(アイランド)がリザルトとして出来上がります。

また、一度この方法で3枚の島を作成してから蓋2枚を筒部分にスティッチ(貼合わせ)すれば、デフォルトUVと同じ「サイコロの展開図」が出来上がることも理解できるかと思います。

この方法のメリットは、UVの継ぎ目(シーム)が最小限であることです。また、連続面が作れますので、立方体を回転させてもつなぎ目の分からない「シームレスなテクスチャ」を描くことが可能になります。

逆にデメリットとしては連続面なので各面を厳密に色分けしたいケースなどには向かないこと、上下左右を考えたテクスチャリングを行わなければならないことなどです。

なにはともあれ、AとBの二つの捉え方で大抵の立体物をUV展開することが可能です。

f:id:kanianthi:20160619144100j:plain

↑こんな風に4隅にベベルをかけて丸みをつけても「蓋と筒」であることに変わりはありません。

同じく…

f:id:kanianthi:20160619144643j:plain

↑なんのことはない、円筒も「蓋と筒」の方法で簡単にUV展開ができます。

最後の難敵→球体

f:id:kanianthi:20160619145359j:plain

↑はBlenderで「UVを生成」をオンにしてUV球を作成し、編集モードでUVレイアウトを確認したところです。

立方体だと見事なサイコロ展開図だったのに比べ、いかにも「ひどい感」がするUVですね。いくら自動生成とはいえ、これはない!とぼくも思います。

しかしながら、数学とか幾何の授業で習ったことはないでしょうか…「球体を二次元に歪みなく完全に投影することは不可能」なのです。

地球儀で見られるメルカトール法などが、かなり「頑張ったやり方」ではありますが、それにしても軸付近で必ず歪みはできてしまいます。どんどんメルカトール分割を増やしていけば「近似値としての球体」には近づいていきますが、完全球にはなりません。

とはいえ…

f:id:kanianthi:20160619150054j:plain

↑3D CGで一般的な球のUV展開はこれです。赤道面にシームを一本入れて、上下に分割して投影するわけです。

眼球のように、極部分のテクスチャさえ正確に描ければ良いのであれば、この方法で間違いなくテクスチャペイントが可能です。しかし、どうしても赤道面(分割面)に近づけば近づくほど歪みは出てしまいます。

そこで

f:id:kanianthi:20160619150859j:plain

このようにシームを一本、赤道から極に向かって引きます。

すると当然、円錐の平面展開のような図形が出来上がりますが、UV面の歪みは小さくなります。ただし、眼球のようなテクスチャをペイントするには向きません。

この方法は、たとえば丸っこい靴のつま先や、指先などのようにカプセル形状に似た端っこのUV展開を行う際に良くあるやり方です。キャラクタでは顔面のUVを展開するときにも、髪に隠れる額の部分や、顎の下などに「切れ目」を入れて歪みのないUVを作成しようとします。

 3D CGモデリングでは「球面(半球)に近似している形状」は良く出てきます。その時々に応じて、赤道面だけのシームで良いのか、切れ目も入れて歪みを少なくすべきか考えてUV展開を行うことが求められます。

さて、今回でUV三人衆を片付けることが出来ました。

次回は、シェーディングの基礎の基礎を交えて、より実践的なテクスチャリングについて説明したいと思います。