読者です 読者をやめる 読者になる 読者になる

当たったらどうすんだよ

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

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

3D CG テクスチャ Blender

ちょっと前回から間が開きましたが、これが通常運行という感じでしょうね。
今回の内容はけっこう重要です。いつも重要なことを書いているつもりではいますが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:シェーディングの基礎と色の話

3D CG Blender テクスチャ

前回までは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の考え方編

3D CG Blender テクスチャ

前回に引き続き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 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の実践的な考え方について進めていきます。

 

ZBとBlenderでUE4用のキャラを作る #10:Blenderキャラに物理で動く揺れモノを!

Blender UE4 UE4にオリキャラを導入したい キャラクタ ゲーム制作 リグ

番外編で「予想していたトラブルに遭遇したけどなぜか外出して帰ったら勝手に解決した!」経緯を書きました。というわけで、ぼくが番外編で書いたように「物理をオンにしたらボーンがひっくり返ったよ!?」みたいな状況に陥ったら「PCごと再起動」してみてください。昔から続く万能の「おまじない」です。

ソースのご紹介

最初に、今回の記事を作成するにあたり、参考にさせていただいたソースを紹介いたします。

unrealengine.hatenablog.com

pafuhana1213.hatenablog.com

docs.unrealengine.com

特にalwei(Twitter id @aizen76)さんにはいくつか質問もさせていただきました。ありがとうございました。

ワサビミドリさんの骨

f:id:kanianthi:20160614222337j:plain

↑画像で示した通り、すでにワサビミドリさんにはモーションがつき、FBX6.1ASCIIでエクスポートも終わっています。この、オサゲ左右に今回はAnimDynamicsノードを利用して簡易物理シミュをつけたいと思います。

もともとUE4内で揺らすつもりだったので、オサゲや前髪に骨は入れましたがモーションはつけていません。なお、もともとはアーマチュアモディファイヤの下に「修正スムーズ(Corrective Smooth)モディファイヤを付けて変形補正をしていたのですが、どうやらUE4では修正スムーズの結果が反映されないようですので、現在のシーンファイルでは外しています。

そのため、若干変形補正用のコンストレインツの付け方やパラメータにも変更を加えました。この辺はサンプルファイルを完成品と捉えず、皆さんで研究していただけたら、と思います。

UE4での基本セットアップ

すでにFBXは用意してありますので…

  1. UE4へのスケルタルメッシュインポート
  2. ThirdPersonAnimBPのリターゲット
  3. 各アニメーションの更新
  4. マテリアルの作成

などの基本的な作業は「すたちゅーさん導入記事」と同様です。

kanianthi.hateblo.jp

ここではそれ以降の部分を解説します。

AnimDynamicsノードをアニメーションブループリントに付け足す

f:id:kanianthi:20160614223725j:plain

↑では同じ「アニムダイナミクス」ノードが二つ並んでいますが、上が左のおさげ用で下が右のおさげ用です。パラメータについても左右が反転しているだけで同じものです。また、こうしたノードの複製はコピペでもいけますので便利です。

また、画像は「walk/Run」ステートになっていますが、AnimDynamicsは、おそらくアニムグラフそのものにもつけられそうですがまだ試していません。とりあえず実験、という意味で、単一ステートではもっとも動きに変化のあるwalk/Runで作業してみました。というか…

f:id:kanianthi:20160614225210j:plain

言ってるそばから、どうせなら修正しておきましょう!とアニムグラフそのものにAnimDynamicsさせる修正を行いました。重複するのでwalk/Runステート内のノードは削除しておきます。

f:id:kanianthi:20160614225339j:plain

続いて、アニムダイナミクスノードを選択すると右ペイン下の詳細パネルに出てくるパラメータを指定します。まずはおさげの根元と先っぽを「チェーン」で指定し、連続した動きになるように設定します。

次に重要なのはBox Extentsという物理シミュ用のダミー立方体の大きさとLocal Joint Offsetによる物理ジョイント位置の補正です。

f:id:kanianthi:20160614230107j:plain

番外編記事でも書いたように、ワールドの座標系とは違い、ボーンのローカル座標軸は「ロール方向がX」になります。つまりボーン軸から見て前(ノーマル方向)がXです。

UE4で描画されるボーンの位置は、Blenderでセットアップした時と比較して「ボーンひとつ分」後退していることが多くなります。これはUE4でのボーン位置は相対的なモノであって、Blenderでモーションをつけるときに行うメッシュとの関係性とは異なるために生じる問題のようです。

f:id:kanianthi:20160614231058j:plain

↑つまりこんな感じ。

upperArmボーン(上腕)がどう見ても肩になっちゃっています。しかし動かすと正常に腕が動きます。なぜこんなことに?というと、LeafBoneと呼ばれる終端ボーンがないからなのですが…とりあえずそこは本題と離れるので今回は割愛し、とにかくモデリングしたときとUE4のボーン位置はズレる。でもBlenderで作ったアニメーションを再生するだけなら問題なし!と覚えておけば十分です。

しかし今回のように、物理シミュレーションはUE4内で生成される動きですから、ある程度ボーン位置を補正しておかないと結果がおかしくなり、異常にリグが暴れたりする結果を招くのです。

物理コンストレインツと簡易コリジョン

まず最初に、今回のセットアップでは

  • X回転はボーンのロール(ねじれ)
  • Y回転は横の揺れ(ヨー)
  • Z回転は縦の揺れ(ピッチング)

となることを理解しておきましょう。

物理シミュは楽しいのですが、好き勝手に物理させておくとあり得ない動きになってしまいます。そこでコンストレイントをかけて動きを制限するのですが、どのようにパラメータをつければ狙った動きになるのか、最初にそれぞれの軸回転の「表現」をイメージしておくことがモーションデザインでは重要です。

f:id:kanianthi:20160614232718j:plain

↑コンストレイント関係はこんな感じです。

Linearは距離でAngularは角度の制限です。それぞれの数値がどう動きになるのかイメージしながら実験し、狙った動きになるまで数値を煮詰めます。おさげがあんまり下に向いて欲しくなければ、正方向の角度制限をきつくすれば良いのではないでしょうか。

最後にPlanar Limitという平面コリジョンを設定します。

今回は胴体(というか胸rib)につけるかと思ったのですが、上腕につけた方が動的な印象が良かったので左右の腕にコリジョンを設定しました。

f:id:kanianthi:20160614233342j:plain

↑画像の半透明緑色の板キレがPlanarLimitです。

妙な青い矢印状のなにかがついていますが、コリジョンの裏表を表示しています。物理シミュを行うボーンに対して、平面コリジョンが裏側を向いていると結果が暴れるのでPlanar Transformの数値でキャラクタに対して後ろを向くようにコリジョンを設定します。(実は最初これが分からなくて暴れる物理にヤキモキしましたw)

以上の設定で呆気なくBlenderで作成したキャラに物理で動く揺れモノが設定できました。数値は作業途中のものですので、サンプルファイルをDLした方は好きなように変更して実験してみてください。

最後にサンプルプロジェクトへのリンクです。

1drv.ms

ワサビミドリさんのBlenderファイルとFBXなどはこっち

1drv.ms

 

 

 

ZBとBlenderでUE4用のキャラを作る #番外編:Blenderボーンの軸について

3D CG Blender UE4 UE4にオリキャラを導入したい キャラクタ リグ

はじめに

今回の記事は研究途中のものです。追加でテストを行っていかないと確かな情報とは言えません。また、各ソフトウエアやゲームエンジン、あるいはファイルフォーマットの仕様変更や更新によって、あっと言う間に「旧い情報」と化すかもしれません。それらを踏まえたうえでご覧くださるようお願いいたします。

Blenderのボーン軸

f:id:kanianthi:20160614195118j:plain

統合型3D CGツールを、Blender以外は触った経験がない方にはなんの不思議もない問題ですが、↑の画像で示した通り、Blenderのボーンはローカルの軸が「Y軸をロール(ツイスト)回転」として設定されています。

またBlenderに標準で備わる機能ではこの回転軸を変更する方法は(ぼくが知る限り)ありません。ですので人体の手足リグを組むさいには、主な回転方向(腕を上げる、膝を曲げるなど)をX回転として設定し、手のひらを反すなどのネジリ方向の回転はY軸回転に必ずなります。

Maya2016のボーン軸

f:id:kanianthi:20160614195948j:plain

続いて統合型3D CGツールの世界ではトップシェアを誇るMayaのボーンです。画像では少し分かりにくいかも知れませんが、X軸がロール回転座標系です。

過去にぼくが触れたことのある大半のCGツールは、Mayaと同じように「X軸ロール」でした。ですので「肩の関節がねじりで破たんするんだよねー」みたいな話題が出ると、それはX軸回転の問題でした。

しかし、BlenderのボーンロールがY軸回転であることは、将来的に他のソフトとボーンアニメーションのやりとりを行うときに、なにか問題が起きるのでは?と心配せずにはいられない事実だったのです。

一般的なスケルトンアニメーションは問題なし

UE4やUnityあるいはCry Engineなども、標準的なアセット作成ツールとしてMayaを挙げているかと思います。当然、Blenderでゲームアセット作成というのは日本国内ではかなりの少数派でしょう。

しかしBlenderでもできないことはない、どころか、一部の機能では他のソフトに優っている面もありますし、ちょっとした工夫を加えることで、それまでBlenderでは実現しにくかった工程があっさり改善されたり、頻繁なアップデートによって激しく機能改善されているのがBlenderの面白さです。

過去の経験から言っても、かなり複雑なモーションを必要とするキャラクタアセット作成においてでさえ、Blenderのパフォーマンスに不満を持ったことはありませんでした。前記したボーン軸の問題にしても、Blender内できちんと動作するアニメーションであれば、UE4にインポートしても(オペレーターがミスをしない限り)どのような問題もなかったのです。

物理アセットではどうか?

ただし…UE4ではビークルというアセットテンプレートが最初から用意されていて、仕様通りにメッシュとボーンを組めば、そのまま「全身が物理で動く自動車」などとして動作させることが可能です。

こうした物理アセットは、基本の骨組みはBlenderで作成できますが、ゲーム(レベル)内での動きはUE4に備わる物理エンジン(Phisics Engine)に委ねられる「プロシージャルモーション」として、その都度計算されながら再生されます。

ぼく自身が過去に「大ハマり」を食らった例として、このビークルBlenderで作成してUE4で動かそうとした例があります。

f:id:kanianthi:20160614202743j:plain

具体的には、上記のように作成した「かんたん自動車」が物理シミュレーションを開始するとタイヤが「90度横を向いてしまう→ホバーかよ!」という状態だったのです。

とっさに思いつくのがUE4の物理エンジンはボーンのロール軸をX回転にしないと正常動作しないのでは?でした。

この「90度の傾き」問題について、当時はUE4内のスケルタルトランスフォームのノードかなにかを使ってなんとか対処しました。しかし、どうしても物理判定用のコリジョンが言うことを聞いてくれず、海外フォーラムにも同様の問題提起がされているのを見つけてはいたのですが、当時は「Maya使えばいいんじゃね?」という、根本的にはなんの解決にもなっていない状況であきらめざるを得ませんでした。

そして再び物理アセットを…

Twitterで少しつぶやいたのでご覧になった方もいるかも知れませんが、UE4.11から、AnimDynamicsというノードを使って、今までよりずっとお手軽に物理を使った揺れモノをキャラクタに導入することができるようになりました。

もともと、今回の連載でワサビミドリさんの「ワサビ型オサゲ」などを、このAnimDynamicsで揺らすつもりでいましたので、昨夜そのテストをしていたのです。

しかし、まさに、アニメーションブループリントにアニムダイナミクスノードを導入し、物理シミュを始めた途端…あの忌まわしい「ボーンひっくり返ったよ問題」が再現されました。昨夜はほとんど、その問題の原因究明と解消に時間を費やしました…。

ところが…

最初に断っておくと、一夜明けて、仕事などで外出して帰宅し、PCを起動しなおしてUE4内でこの記事を書くためのスクショを取ろうとしていたら「あれ?」と気付いたのですが、どういうわけか「ボーンの軸ズレ問題」が消えてなくなっていましたw

ぼく自身、どうして解決したのかさっぱり分かりませんが…敢えて言うなら「なんらかの累積エラーがメモリ上に乗っかったまま騒いでいた」ということなのでしょう。

とはいえひとつの解決の糸口として

上記したように、確かな理由は分かりませんが、ワサビミドリさんのオサゲは、今では正常に「アニムダイナミクスって」います。

 しかし、それ以前の「無駄手間だったかも知れない試行錯誤」の中で、ひとつの方向性は見出すことができました。ですので万が一「Blenderでボーン付きアセットを作成して解消困難な問題が出てしまったとき限定の解決策」として、これを紹介することにします。

というのは…UE4内でもボーンの向きを変換するためのノードはあります。しかしこれは、ひとつひとつのボーンについてセットするものですので、いくつものチェーンになるボーンがおかしな向きになってしまった場合などでは、ほとんどお手上げです。

docs.unrealengine.com

それではBlenderからFBXとしてキャラクタを出力する段階ではどうでしょうか。

今まで推奨してきた(そして今後も推奨する)FBX6.1ASCIIフォーマットでは、ボーンの軸や向きを変更するためのプロパティはありません。

しかし!

f:id:kanianthi:20160614205423j:plain

↑FBX7.4バイナリ形式ならできるのです!

これができるのであれば、FBX7.4バイナリ形式をUE4への標準書き出しフォーマットにしたほうが「良いのかも」しれません。しかし、国内でも海外でも「FBX7.4だとアニメーションが正常に書き出されなかったり、一部(だけ)マテリアルがおかしくなるなどの問題が出る」という報告があるのも事実です。

またあるいは、Blenderのバージョンアップによって(本記事では2.77a)FBX書き出しアドオンの改善がされたのかも知れませんし、UE4側のFBX受け入れに変更があったのかも知れません…ですから、さらに多くの追試を行わないと、だったらFBX7.4でいいじゃん!と断言はできないのです。

結果的に、このようなボーン軸の変換を行っていないはずのFBX6.1ASCIIで書き出したワサビミドリのUE4アセットも…

f:id:kanianthi:20160614210521j:plain

↑画像のように、きちんと「標準フォーマットである」X軸ロールに変換されています…ん?本来はFBX6.1ASCIIで出力するだけで、勝手にボーンロール軸をXに直してくれるの?とか、色々考えましたが推論に過ぎません。しかも、昨夜は確かにロール軸がYのままでした…ぼくが寝ぼけていたか幻覚を見ていたかしたのでしょう…

というわけで、これまで「安定性」で実績のあるFBX6.1ASCIIで問題がないのであれば、よりステーラブルな方法を実践するべきだ、とぼくは思います。

しかしそれでも、(6.1に比較し)より改善されたフォーマットであるはずのFBX7.4を使いたいのでしたら、それはそれでメリットがあるの「かも」知れません。現にぼく自身が、PCを起動しなおしてもボーンのひっくり返り現象が継続していたなら、FBX7.4にワークフローを移行していたでしょう…。

結論的に結論はありません!なんだか良くわかんないけど直った!が結論です。

しかし、これらの現象および試行錯誤について、十分に理解のある知識と技術をお持ちの方には有用な情報になる、と判断しましたのでこの記事を公開します。

それでは次回は、AnimDynamicsを使った揺れモノの実装についてです。

 

ZBとBlenderでUE4用のキャラを作る #9:Blenderで人物リグ完成!

Blender UE4 UE4にオリキャラを導入したい キャラクタ ゲーム制作 リグ

この連載も早いもので第9回。
今回でBlenderによる人物キャラクタ用リグを完成します。

f:id:kanianthi:20160611192300j:plain

↑完成図はこれです。
複数人でチームを組んでリグというよりアニメーション作成を行う場合では、選択のしやすさや動かしやすさを考慮してコントロール用ボーンとルートボーンには、カスタムシェイプを割り当てて表示するようにすべき、とは思います。しかしぼくの場合は基本的にソロ作業のぼっち虫なので、分かればいいや!で済ませてしまいますw

前回から多少の試行錯誤を加え、大腿骨(thigh)の補正ボーンの動きと数値の適性値を探ったりはしましたが、基本的に当初の計画通りにリグを仕上げ、結果の動きにもある程度満足しています。

リグの構造

何度か書いていますが…

  • すべての親となるrootボーン
  • 脚はIK、その他はFKで駆動
  • 主要な破綻しやすい関節に変形補正用ボーンとインフルエンス(コンストレインツ)を組み込む
  • 前腕にはツイストボーン(2分割)い
  • リバースペルビスと背骨ロールセンター(コントロールボーン)
  • 揺れモノはUE4の物理ノードで作成する

以上を仕様とします。

f:id:kanianthi:20160611194137g:plain

↑変形補正ボーン(インフルエンス)の動作はgifで見る方が分かりやすいですね。
こうした仕掛けを股関節に3か所、膝と肘、それに脇の下に仕込んであります。

さらに必要であれば、ボーンの固定は行っていませんので(rigifyでやるように)位置や回転を動かして適切な変形になるように追加補正も可能です。

Blenderでボーンをミラーコピーするときの注意点

f:id:kanianthi:20160611194940j:plain

ボーンは片側だけでIKやコンストレインツを組み、あとで逆側にミラーコピーします。
しかしそのとき、↑のキャプチャで示した「ボーンロール」が正常に反転せず、ポーズのミラーコピーができなくなる現象に出くわすことが「かなりの頻度で」発生します。

これがBlenderの仕様なのか不具合なのかバグなのかはっきり分かりませんが、とにかく左側で46.66度のロール角であるなら、右側では-46.66度になって正常です。ポーズモードでポーズの反転コピペを行って正常な結果が得られない場合は、ボーンロール角がおかしなことになっていないか確認してください。

クオータニオンオイラー

f:id:kanianthi:20160611195722j:plain

別の記事でも書いていますが、rootボーンなどの「全身を回転させるのに使うボーン」はオイラー角で運用したほうが圧倒的に楽です。なぜなら、クオータニオンでは360度回転をさせるためには「最小角度のルール」によって大量のキーを打たなければならなくなるからです。

今回のリグの場合、オイラー角でキーを打つのはrootボーンとROT_spineボーンの二つになります。1軸しか動かさないのであれば脛や肘のボーンもオイラー角で構いません。

ウエイトペイントについて

f:id:kanianthi:20160611200940g:plain

いつものことですが、ウエイトペイントには大して時間がかかりません。
ほとんど自動ウエイトだけで↑のgifくらいの変形が行えるようにメッシュと骨をセットアップしていますので、調整が必要なのは各補正用ボーンと骨盤、spine(背骨)くらいです。

ウエイトペイントで半日も時間がかかるケースというのは、恐らく骨の位置やメッシュの構造が間違っているからです。できる限り自動ウエイト一発で「とりあえずきちんと動いているように見える」関節の位置を探ってみてください。

必要なボーンにだけ頂点グループとウエイトをつける

f:id:kanianthi:20160611202528j:plain

↑画像は「おさげ」のボーンに手動ウエイトペイントを行っているところです。

頭部パーツや目、髪の毛パーツなどのように、首から下のボーンの影響を一切受ける必要がないメッシュには「アーマチュア変形」でボーンとメッシュの関連付けを行い、その後ウエイトペイントモードで個別にボーンを選択し直接ウエイトを塗っていくか「ウエイト→ボーンから自動割り当て」を使い、半自動で頂点グループを作成していきます。

また、目のパーツのように頭のボーンだけに100%のウエイトがあれば良いケースであれば「空のウエイトで」を使ってボーンと関連付けを行い「head」頂点グループを作成し、ウエイト値に直接100を入力すれば終了です。

リグの詳細については骨そのものに触れていただき、試してみるのが一番だと思います。今回もサンプルファイルへのDLリンクを貼っておきます。

onedrive.live.com

なお、ワサビミドリのUE4用キャラクタモデルに関しては、以下の利用規約を念のために設けておきます。

  • メッシュ、リグ、テクスチャデータなどのすべてにおいて、作者である「なん」は権利を放棄しませんが、使用者の利用に制限を加えることもいたしません。メッシュの改造、リグの改良など、ご自由に楽しんでください。
  • このモデルを使ったBlenderファイルやUE4プロジェクトなどの配布、再配布もご自由に。ただし、なにか楽しい変更をしていただいた場合、ご一報いただけるとうれしいです。
  • 商用利用についても制限は行いませんが、ビルが建つほど儲かった場合は部屋のひとつくらいの分け前をいただければうれしいです。