当たったらどうすんだよ

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

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

こんにちは、なんです。
この記事は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三人衆を片付けることが出来ました。

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

 

 

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

今回から3D CGに必須のテクスチャリングについて少し書きます。
例のごとくBlenderを対象アプリケーションにしていますが、どんな3Dソフトでもまったく同じ考え方が通用します。基礎の基礎をきちんと理解して、その応用として高度なテクスチャリングを作れる「入口」に到達していただくのが目的です。

よくある解説では、UV展開のやり方そのものをソフトウエアの機能をベースに解説しています。なぜUVが必要か?はともかく、どういうUVが良いの?という部分がすっぽり抜けていて、いきなりシーム引いて展開コマンド入れるとほらできた!みたいな記事になっていることが多く、それでは機能解説に過ぎないのです。

今回のお題

f:id:kanianthi:20160619012453j:plainBlenderのシーンに現れたUV3人衆です。

とりあえずこいつらのUVを「きちんと開ける」ようになることが最初のステップです。多少複雑なモデルやキャラクタになったとしても、この3つを的確にUV展開できるようになっていればあとはその応用に過ぎません。

最初の敵:立方体は一番面倒

立方体というかサイコロ…こいつがですね、なかなかどうして難敵です。ハードサーフェースモデリングでも出てくる問題がいきなり発生します。

f:id:kanianthi:20160619013256j:plain

↑ちなみにBlenderに最近備わったのがコレ。
デフォルトでプリミティブにUVをつけてくれます。なんだいきなり解決じゃない!って?そんなわけありませんw

UVの展開法ではなく、展開するための考え方を説明するために、敢えて自動生成したUVで「あー面倒くせー!」って状況を実感していただくことが目的です。

さて…こうやってUVを自動生成した立方体に、いきなりテクスチャリングをしてみましょう。TABキーなどでテクスチャペイントモードを選択するだけです。

f:id:kanianthi:20160619013904j:plain

すると↑の画面になるはずです。
立方体がマゼンタ色に見えているのは、まだマテリアルもテクスチャも設定(生成)されていないからです。

f:id:kanianthi:20160619014146j:plain

そこで、ペイントスロットを追加します。Blenderには上記のペイントスロットが備わっていて、なにげにいろんなテクスチャを塗れます。PBR時代の今では若干古臭いスロットもあるにはありますが、かなり高機能ですね。

今回はディフューズ色を作成します。ブランクテクスチャが生成されて、立方体が真っ黒になれば正解です。続いて画面下のペインをUV/画像エディターにしましょう。

f:id:kanianthi:20160619014937j:plain

↑今回はBlenderのペイント機能を解説したいわけではないので、ちゃちゃっとマウスで「あいうえお か」を書きました。立方体なので6面あります。UVエディタには、まさに「サイコロの展開図」が表示されています。

さていきなり分かることは…文字の向きが「えかいお」と「あ う」で上下が逆転していることですね。これは現実に立方体を展開してみてもまったく同じ問題に遭遇します。UV展開ができた!よし塗るぞ!とフォトショップなどでテクスチャを描いてみたら…上下があちこちでおかしくなってしまった!なんて状況は、以前よくありましたw

ただし最近では、どんな風にUVを展開していたとしても、Blenderのペイント機能やフォトショップの3Dペイント、Zbrushなどを利用してサンジゲンのオブジェクトに直接ペイントすることが可能になりましたので、随分と楽です。

UVの考え方、そのいち

というわけで、今ほど体験した通りです。UV展開したー!よし塗るぞー!あれ?上下違うじゃねーか!!というのは、かなりよくあるお話しです。しかしこれは、UVに特有の問題なわけではありません。

立体物を二次元に投影/展開すると必ず起きる問題

なのです。

そこで、今のように3Dペインティングが普及していなかった時代にはUVレイアウトを画像として出力し、それをテンプレに2Dソフトでテクスチャリングしていたので…

f:id:kanianthi:20160619022134j:plain

↑のように、すべてのUVアイランドでテクスチャの方向が一致するようにすべてYアップにしておいたりなど、テクスチャを2Dの状態で描きやすいように配置するなどの工夫がありました。

現在でも、3Dペインティングの修正や補正にフォトショップなどの2Dワークフローを利用することはよくあります。そのときに「2DペイントしやすいUV」だったら、修正作業もとても楽になります。

このようにUV展開では、その後の作業を見据えた、テクスチャリングを楽にする展開と配置が大事になりますよ!というところで今回はここまで。

次回もUVの実践的な考え方について進めていきます。