UE4：Shell Based Stroke Material
ピッグのアヌシー受賞のお祝いとして制作した映像のマテリアル表現をまとめました。
受賞発表の熱が冷める前にお祝いしたかったので、約1週間で映像を制作しています。まだまだ荒削りなアイデアですが、個人的には発展させると面白そうな、良い匂いのするテクニックだなと思っています。(水彩ポストプロセスとの合わせ技とかも面白そうです。)
ブタくんの表現的な目標
お祝い動画は、下記を目標にしました。
- Dice氏 の描くコンセプトアートのタッチで、ブタくんを動かしたい。
- (3Dが苦手とする) キャラと背景の境界をなじませる手法の試作。
- 水彩ポストプロセスとは、違うアプローチでの NPR を模索。*1
アイデアのベース
前回の水彩ポストプロセスがほぼ 100% ポストプロセスで行なっていたのに対し、ブタくんは 80 ～ 90% はオブジェクトのマテリアルでビジュアルを作っています。
テクニックのベースはポリゴンの積層(通称：Shell法)です。ベースとなるメッシュを複製してノーマル方向に押出し、ストロークのテクスチャを貼っています。これが積層になることで、厚みのある重ね塗り表現にしています。(メッシュの構造としては、ワンダと巨像の Fur と同じと言えば通りが良いでしょうか。)
また、積層メッシュに割り当てるマテリアルは、輪郭部分のみ表示されるように処理を組んでいて、そこにストロークのマップを合成して、ブラシの見た目にしています。
※クリックで拡大します。
用意したデータ
モデル
8層のShell構造を持ったブタくんのスケルタルメッシュ。 ブタくんのメッシュができたあと 7つ 複製し、同じマテリアルを割り当てています。8つのメッシュの違いはマテリアルインスタンスのパラメータのみです。輪郭にストロークを適用すると太って見えるため、メッシュは細く調整しました。
テクスチャ
今回は作業効率優先のため、チャンネルの統合はしていません。1チャンネルしか使わない要素も、テクスチャを1枚使っている贅沢仕様です。
| イメージ | 用途 | 説明 |
|---|---|---|
| Base Color | 通常の ベースカラー です。特殊なことはしていません。 | |
| SSS | 通常の SSS です。 | |
| Stroke | 重ねるタッチ用のマスクです。今回の絵作りで重要な要素になります。このテクスチャを変えるとタッチも変わるので、模索すると面白そうです。 | |
| Stroke Normal | ストロークの凹凸情報です。あまり強いと、立体感が強調され 3Dモデル っぽくなりすぎるので、程々に調整すると良い結果になりました。 | |
| Push Strength | アウトライン用のメッシュの押出し強度を追加するマップです。トトロで使ったものと一緒です。 | |
| Push Strength Random | アウトライン用メッシュの押出し強度にゆらぎを与えるマップです。Noise に Blur をかけた画像を使っています。 | |
| Ambient Occlusion | 通常の手順で焼いた Ambient Occlusion マップ。目指す絵によってはなくても良いです。ブタくんも、ストロークの印象が強いので、あまり効果は出ていません。 |
※Metal・Specular・Roughness はスカラー値で調整するため、テクスチャは用意していません。
マテリアル：Shell Based Stroke
今回の Shell ベースのペイント表現の手順を解説します。
手順としては、
- 頂点シェーダで、メッシュを法線方向に押し出す。
- 「カメラベクトル・メッシュの法線」の計算で輪郭部分のみ表示されるように Opacity を調整。
- 2 の結果にタッチを追加
- UVステップ (テクスチャ・バーテックス)
- 着彩 (BaseColor を適用)
となります。
これを複数レイヤー重ねると、ストロークが重なるわけです。
ポストプロセス：Stroke Bloom
タッチを施した後、輪郭部分の色を飛ばすため、色を加算させるポストプロセスを適用しています。これによって、明るい部分を誇張して白く飛ばす表現をしています。（1階調増えるように見えるため立体感が増します。ですので、目指す絵柄によってはなくても良いと思います。）
- Scene Color から、輪郭部分を抽出
- Scene Color から、明るい部分を抽出
- 1と2から「明るい輪郭部分」を抽出
- 3をマスクとして利用し、その部分にある色をブースト。
4の処理を変えることで、絵柄を変えることも出来ます。
サンプルデータ
注意事項
- サンプルデータは Unreal Engine 4 (ver 4.17.2) で制作しております。
- 最適化などを行っていないデータですので、そのあたりを承知のうえでご利用いただける方のみダウンロードください。
- ブタくんを配るのはまずいのでシンプルなオブジェクト・テクスチャ(Base Color・Touch Mask)を置き換えています。
- データについて、気づいた点や間違っている点などあれば、都度改善していきます。Twitter か 記事へのコメントで教えていただけるとありがたいです。
個人的な振り返り (読まなくていいやつ)
最初に設定した目標が全部達成されたかというと...
- Dice氏 の描くコンセプトアートのタッチで、ブタくんを動かしたい。
- (3Dが苦手とする) キャラと背景の境界をなじませる手法の試作。
- 水彩ポストプロセスとは、違うアプローチでの NPR を模索。
1の Dice氏のタッチは完全再現出来ませんでした。途中でテクニックに踊らされ、ゴールがぶれてしまいました。まだまだ改良の余地ありと考えています。2, 3 については、満点では無いですが、自分としては手応えがあったので、もう少し深掘りしたいなと思っています。
引き続き実験してみます。
*1:水彩のテクニックは、実際にゲームで使うとなった場合は制約が多いので。
UE4 : 水彩 Post Process Material
大昔に行った FXTree でのコンポジットを、Unreal Engine 4(以下 UE4)で再現しました。肝となるテクニックは、色を塗りたいところにマスク(白黒)を用意し、その領域をズラしたり歪めたりして色を重ねるものです。ほぼ100% Post Process で絵作りを行っています。
まだまだ作りたてのマテリアルで最適化もしておらずパラメータ調整もピーキーで実用性についてはまだまだです。そのあたり興味がある方は改良してお使いください。
用意したもの
モデル
メッシュを2重化したスケルタルメッシュ。1つは実体。1つはアウトライン用。
アウトライン用メッシュは、実体のメッシュをデュプリケートして法線を反転しています。
アウトラインの太さは、マテリアルの押し出しで制御していますので、データの時点では実体用メッシュとアウトライン用メッシュの頂点位置は、完全に重なっています。
テクスチャ
テクスチャは1枚。
RGBのチャンネルに、下記要素を持たせています。
| RGB | イメージ | 用途 | 説明 |
|---|---|---|---|
| R | Paint Area | 色を塗るエリアを、白黒の濃度(今回は16段階)で塗り分けたマップです。決め打ちで14段階目のグレー はアウトライン。16段階名のブラックは背景。として利用しています。 | |
| G | Paint Outline | アウトラインを追加するマップです。アウトライン用メッシュは形状が平坦なところではラインが出ません。それを補足するため、テクスチャでラインを追加します。今回はトトロのお腹の三角形の模様部分に使っています。詳細は後述。 | |
| B | Push Strength Outline Mesh | アウトライン用のメッシュの押出し強度を追加するマップです。目の周りはアウトラインを細く、お腹のピーク部分は太くなど、場所によるアウトラインの太さを制御します。 |
マテリアル
カスタムマップ(または計算した値)を、それぞれの Buffer に書き出すマテリアル。
頂点を法線方向に押し出す頂点シェーダを追加したもの。
| 要素 | 用途 | 説明 |
|---|---|---|
| Buffer : Subsurface Color | Post Process で色を塗る領域を指定 | 通常は SSS として書き出される Buffer : Subsurface Color を色を塗るマスクとして利用します。 |
| Buffer : Metallic | アウトラインにテクスチャで描いたものを追加 | 通常は金属・非金属情報を指定する Buffer : Metallic を、アウトラインの追加要素として利用します。 |
| World Position Offset | 頂点を法線方向に移動 | Material Function : MF_PushVertex を利用し頂点を移動させます。先にゆらぎを与えるため、ノイズのテクスチャで、押し出す距離に強弱を与えます。 |
ポストエフェクト
- 水彩マテリアル ※後述
- カスタムケラレ・色収差
水彩マテリアルの後に、処理を行う必要があるため、簡易的な処理を自作。
水彩マテリアル内の処理について (3点)
処理の詳細はサンプルデータを見ていただくのが一番ですが、処理内容を読み解くガイドとして、水彩マテリアルの肝になっている考え方をいくつか解説します。
1. 「Buffer : Subsurface Color」からマスク領域生成
2. 1で生成したマスク領域を利用したペイント
3. アウトライン生成
特に "1" が一般的なUE4の考え方から外れていると思います。ここがすんなり飲み込めれば、あとはよくある系の処理になっています。
1, 「Buffer : Subsurface Color」からマスク領域生成
「Buffer : Subsurface Color」に出力されたテクスチャを、色を塗る領域として利用しています。「Material Function : Separate ID」を利用して特定のマスク領域を抜き出しています。
抜き出された領域をベースにして色を塗っています。 今回はトトロ 1体しか出ないので、16段階で抜き出せる仕様にしていますが、理屈上は1チャンネル256段階までいける(?)と思います。 (若干精度や、処理負荷の心配がありますが)トトロは背景・アウトライン合わせて、下記12領域使用しています。
| ID | 用途 |
|---|---|
| 1 | 体(薄い緑) |
| 2 | お腹(ベージュ) |
| 3 | お腹の模様(薄い緑) |
| 4 | ひげ(黒) |
| 5 | 鼻(茶色) |
| 6 | 爪(黒) |
| 7 | 歯(白) |
| 8 | 口(赤) |
| 9 | 黒目(黒) |
| 10 | 白目(白) |
| 11 | 未使用 |
| 12 | 未使用 |
| 13 | 未使用 |
| 14 | アウトライン(深い紫) |
| 15 | 未使用 |
| 16 | 背景 |
2, 1で生成したマスク領域を利用したペイント
1で生成した領域は3Dモデルの形状通りなので、そのまま着色すると、アウトラインからはみ出すような水彩の着彩には見えません。そこで、マスク領域に歪みや滲みを加えていきます。
加えている処理は大きく「歪み」「ノイズ」「塗り位置のズレ(アウトラインから色がはみ出す)」「塗りムラ(塗りの濃さ)」「液溜まり」です。
歪み
UV のオフセットの値を、水面の歪み(上記テクスチャ)の値でズラす。
ノイズ
FxTreeでやっていた時は、ノイズのフィルタを使っていましたが、そのような処理はUE4にないので、事前にノイズをかけたテクスチャで代用しています。今回は2種類使用しました。
塗り位置のズレ
Buffer の UV をオフセットし 3D モデルの位置から色をズラします。
塗りムラ・液溜まり
デイフーズの計算結果に、コントラスト・明度調整したあと、リムライト部分を乗算し、輪郭部分の色を塗らないようにします。また、水彩画の特徴のハイライト部分は、下地を活かし、色を塗らないよう、ハイライト部分のマスクを黒に塗る(色を塗らないよう)処理をしています。
ただ、個人的にはもう少し煮詰めたい処理で、さらに水彩の筆致を詰めるならこの処理の改善が必須だと考えています。
影(セルフシャドウ)
シャドウは ON / OFF できるようにしています。無い方が絵的に見える部分と、ある方が情報量がまして品質が上がっているように見える部分を分けるようにしています。個人的にはセルフシャドウがあると立体感が増し ３D感 が出てきてしますので、極力 OFF で利用しています。
3, アウトライン生成
アウトラインの処理も基本的には上記2と同じ(領域を塗る)です。ただ、いくつか処理が違う点を解説します。
アウトラインは Separate ID で抽出した領域だけではなく「カメラから見たときに直行している面 (Camera Vector・Normal)」「テクスチャで書き込んだアウトライン(カスタムマップ G チャンネル)」の3種類を合成し、色を塗る領域として利用しています。これにより、ディティールが細かい部分や、形状的にアウトライン用メッシュでは線が引かれない部分にもラインを引けるようにしています。
サンプルデータ
記事で説明したポストプロセスを共有します。基本的には好きに分析・改良・改造してもらって構いません。
注意事項
- サンプルデータは Unreal Engine 4 (ver 4.17.2) で制作しております。
- 最適化などを行っていないデータですので、そのあたりを承知のうえでご利用いただける方のみダウンロードください。
- トトロを配るのはまずいのでシンプルなオブジェクトに置き換えています。
- データアップが初めてですので、気づいた点や間違っている点などあれば、都度改善していきます。Twitter か 記事へのコメントで教えていただけるとありがたいです。
使い方
- 上記アドレスの「Clone or Download」から Download ZIP を選択。
- ダウンロードしたファイルを解凍。
- \WaterColor-master 内 PJ_WaterColor.uproject を開く。
- \WaterColor-master\Content\WaterColor\Maps\WaterCOLOR.umap を開く。(軽量版の WaterCOLOR_Light.umap も用意しております。)
再現：スタジオジブリさんの水彩コンポジット
7,8年前、スタジオジブリさんがWEB上で解説していた水彩コンポジットを再現してみました。当時、その解説を見ながら再現を試みたのですが、コンポジットの熟練度が低かったので完全再現出来ず放置していました。
そのシーンを久しぶりに発掘してみたら、 何となく再現が出来たので解説してみます。(当時はギブリーズ episode2公開前後で、FxTreeの前身である、Avid Media Illusionという独立したソフトを使って解説されていましたので、Avid時代のユーザー事例とかだったかな？と思います。)
この手法を使うと、普通のSphereオブジェクトが下記の様なタッチになります。
用意する素材
今回は効果がわかりやすいように、Sphereをベースにコンポジットしていきます。まず、SphereをDiffuse・Specular・Shadow・Depth・Normal・Outlineの計6種類の要素でレンダリングします。
水彩コンポジットの基本となる処理
次に上記の画像にエフェクトをかけては合成を繰り返し、水彩の特徴である滲みや、アウトラインから色がはみ出る表現を2D的に再現していきます。今回は、Sphere本体と影部分に色をつけたいので、下記の様なFxTreeを組みました。
上記のレンダリング素材を使用し、基本となるコンポジットを行っていきます。今回はSphereの下地部分のコンポジットを例に手順を追っていきます。
1, ColorCorrect(Diffuseをコントラストアップ)
2, MathComposite(1の結果 x Specular。必要なスペキュラ要素だけ取り出す)
3, ColorCorrect(コントラストアップ)
4, Invert
5, ColorCorrect(ノーマル素材のコントラストアップ)
6, MathComposite(4の結果 x 5の結果)
7, TurbDistor(歪める)
8, MedianFilter（ノイズ除去目的ですが、Sphereみたいに面積が広いとあまり効果はわからないですね）
9, Resize(スケールとポジションオフセットを行い、枠からハミ出す処理) 【素材A】
10, FastBlur(今回は720pで30pixel位)
11, Noise
12, FastBlur
13, ColorCorrect(彩度を0に)
14, Resize(17で行う合成の目的である、光源方向の滲み表現のためのリサイズ)
15, MathComposite(素材Aと、差で合成)
16, Invert【素材B】
17, MathComposite(colorと素材Aを乗算)【素材C】
18, Composite(背景素材に対して、素材Cを、素材Dのマスクで合成)
これで、Sphereの下地部分の完成となります。
できあがり
これらのコンポジットの流れを、Sphereの下地部分以外にも処理します。(各部位でのパラメータのバラツキは、見ながら調整)
Sphere・下地
Sphere・液溜まり
Sphereの影・下地
Sphereの影・液溜まり
そして、背景に上記素材をコンポジットしていくと完成となります。
完成した動画がこちら。
水彩コンポジットの応用
せっかくなのでSphereだけでなく、キャラクターにも応用してみました。
ジブリといえば、トトロ。
ジブリさんのコンセプトアートによる水彩画は、影部分にタッチが入っている事が多いので、よりそれっぽくするなら、タッチ表現を詰めても良いかもですね。
まとめ
今回の水彩コンポジットでポイントとなるのは、2Dベースのコンポジットで絵作りを行うということです。ゲームのキャラクターを絵的な表現を行う場合、どうしても個々のオブジェクトに割り当てるシェーダーに頼りがちですが、そうすると水彩のタッチが出せたとしても結局フィギュアの表面に、水彩絵の具で色づけしただけの表現になってしまい、画面全体で見るとどうしても絵的な見た目にはならない問題がありました。
このコンポジットの考え方を利用すると、水彩以外の絵の要素でも特性を分解し、それぞれをコンポジットで積み重ねていくと言った表現が出来るようになるかもしれません。
今年のE3を見ていると、次世代のゲームグラフィックはフォトリアルな方向に爆進中ですが、これらのNPR(スタイライズド)表現に力を入れるタイトルが出てきても面白いと思うので、その辺り期待したいですねぇ〜。
あと、上記のメイキング動画を作ろうと思ったのですが、慣れて無いこともあり挫折してしまいました…。また再挑戦してうまく出来れば公開したいと思います。それでは〜。
スクリプト処理速度比較「VBS・JS・Python・C++」
先日Softimageのスクリプトの事で調べ物をしていたら、Softimageのスクリプト言語での処理速度を比較するという面白い記事を見つけました。(myaraさんのサイト、他のスクリプト記事も濃くて面白いです＾＾)
今までスクリプトの処理速度は気にした事が無かったので「VBS、意外と速いんやなぁ〜」と興味深く読んでました。ただこの2年間くらいはPython縛りでプラグイン作成を統一していた自分にとっては、Pythonの速度比較が気になるところです。という訳で、今回は上記記事を参考にSoftimageのスクリプト言語での速度比較をしてみました。
はじめに
題材にしたのは、上記記事にあったXSIBaseのスクリプト。処理の内容はというと、
・選択しているポリゴンオブジェクトを取得
・ポリゴンオブジェクトのエッジを取得
・全てのエッジを検証。エッジに隣接しているポリゴン(neighbor polygon)が2つ以上あるか判定
・2つ以上あれば、各ポリゴンの法線ベクトルを取得
・2つのポリゴンの法線ベクトルの差が、指定した値以上であればエッジを選択
というような感じです。今回の速度計測で使用したオブジェクトは、恒例のスタンフォードドラゴンをリダクションしたものを利用しています。（そのままだと処理時間がかかりすぎたので…。）
まずはこれをmyaraさんの記事に基づいて最適化したものをベースで利用しています。最適化の概要は「option explicitを利用した宣言の徹底」と「特定のエッジを発見した時に、その都度選択を行う処理を止め、一旦配列に保存して最後に一括選択」が大きなところです。このスクリプトで、処理時間的には下記の通りとなりました。
スクリプト 処理時間（秒） VBScript 593.6172 VBScript(最適化) 7.1118
確かに速くなりました。しかもかなり！書き方でこんなに変わるものなんですね。
スクリプト毎の比較
さて、上記で最適化したVBスクリプトを他の言語にも移植していきます。今回はJスクリプト、Python、あとC++でdll化したものも用意してみました。どれも処理内容は同じものです。で、結果はこちら。
スクリプト 処理時間（秒） VBScript 7.1118 JScript 8.7450 Python 100.1579 C++ 1.8930
Python遅いっ！圧倒的に処理時間がかかっています。これはどういうことなんでしょう…。処理の流れは同じはずなんですが…。
そういえばC++で作ったdllはプラグイン形式で、他の言語はスクリプトの直接実行なので、その辺りが影響しているのかなと思い、他の言語もプラグイン化してみました。
そして結果はこちら。
スクリプト 処理時間（秒） VBScript 7.1118 (秒) VBScript(Plugin化) 6.8593 (秒) JScript 8.7450 (秒) JScript(Plugin化) 8.5820 (秒) Python 100.1579 (秒) Python(Plugin化) 99.3639 (秒) C++ 1.8930 (秒)
うぅん速くなっているようですが、体感速度的には誤差程度の差しか無かったですね・・・。（マクロ的な使い方をしていれば、体感的に速くなる印象があるので、今回みたいなエッジをforでループと言う処理内容では結果が出にくいのかもしれません。）
まとめ
というわけで、今回の比較ではPythonが遅くて、VBスクリプトが速いという結果になりました。
最近は時流に乗ってプラグイン制作では全てPythonで統一を考えていましたが、VBスクリプトを見直しました。よくよく考えるとSoftimage自体に入っているプラグイン自体の大半がVBスクリプトで書かれているので、そこで気づくべきでしたね。
Pythonの構文はシンプルで行数も少なく、アーティストには優しい言語だと思っているので、今後も使用を継続していくと思いますが、処理速度を求めるところはVBスクリプトで書くという選択肢は考えた方が良いかもですね。
あと最後に、今回使ったスクリプト・C++のソースはダウンロードできる形にしています。もし「Pythonはこう書いたら速くなるよ〜。」とかヒントがあれば、ぜひコメントいただければと思います。自分もその方が助かるので…。
では！
「Ragdoll」開発事例〜MayaからUnityへのアプローチ〜 レポート
先日参加した「3DCGツールとUnityによるゲーム開発実践セミナー」のレポート、2つ目です。先日のSEGAさんのレポート同様、実践的で非常に濃い内容でした。こちらのレポートもGamewatchさんの記事と合わせてご覧いただくと、セミナー内容がうまく補完できるかと思います。
- GameWatch - オートデスクとUnity、「3DCGツールとUnityによるゲーム開発実践セミナー」開催
追記：2012年2月28日(08:00)
- Insideさんにも記事が掲載されていました。写真も豊富で素晴らしいです。
プロジェクト概要
- スケジュール
- 2010年末 企画提案
- 2011年1月 開発スタート
- 目標：短期間・低コスト・成果
- 早い・安い・うまいを目指したプロジェクト
ゲームの内容
- 手芸の一つ、編みぐるみ・ぬいぐるみをスマートフォンで手軽に楽しむ事が出来るアプリ
- https://market.android.com/details?id=jp.gree.android.pf.greeapp3130
チームの目標
- 早い
- 早く結果を見てもらえる
- 自社ブランドでの開発となったので、短期的に成果を見せる必要があった
- 安い
- 予算が少ない
- うまい
- やりたい事が実現できる
初期メンバー
※D = ディレクター、PL = プランナ、PG = プログラマ、GD = グラフィックデザイナー、TA = テクニカルアーティスト。
（2012年3月4日 22:40コメント欄で頂いた内容を元に修正しました。）
必要要件
- リアルに見える
- 編みぐるみ・ぬいぐるみを実際に触っているように感じる質感表現
- リアルに揺れる
- ラグドール演算
- 自由に作れる
- かわいい（必須）
開発環境
- Autodesk Maya 2011
- Unity2.1 〜 2.4.2
Unityを選択した理由
モデルパーツの作り方
- 全てYupで制作
- ゲーム中に編みぐるみをエディットするため
- 手・足などのパーツは、胴体パーツの各頂点の法線方向に向く仕組み
マテリアル
- 全てのマテリアル設定はUnity上で行った
- 使用したのは、Strumpy Shader Editorアセット
- http://u3d.as/content/strumpy-games/strumpy-shader-editor/1C4
UI
- 通常のUIはEZGUI、リッチなUIはMayaで制作
- なぜEZGUIなのか？
- Unity標準のGUIテクスチャーでの不都合
- 複数の画面解像度・縦横比に対応が困難
- 表示が崩れる
- マテリアルがまとまらない
- 同じテクスチャを利用していてもDynamic Batchingが働かずDraw Call数が増える
- EZGUIの利点
- オブジェクトが3D座標上にセットされる
- 解像度・縦横比に依存されない
- マテリアルをまとめるとDynamic Batching が働く
- Draw Call 数軽減
- MayaでのUI制作
- 動きの多いメインメニュー画面（地球）は全てMayaで制作
- 各オブジェクトの挙動はMayaで制作したアニメーションを流す
テクスチャの容量削減
- アトラス
- アプリ本体の容量軽減のため、複数のテクスチャを一つにまとめる
- アトラスの問題点
- 特定のテクスチャしか使っていないシーンでも、まとめた大きなテクスチャを読むようになりロード時間増大
- 一部のデータ修正でも、まとめたテクスチャ単位で更新が必要になる
- Asset Bundlesの使用
- 特定のデータをアプリ内に持つのではなく、サーバーなどに置いておく
- 実行中にデータをサーバに読みに行く
- Ragdollではシーン毎にAsset Bundles を作成
- ダウンロードしたAsset Bundles はローカルに保存
- アプリの起動時に更新を確認し、更新があればそのデータだけをダウンロード
- アプリの更新をする事なくデータ更新が出来る
- Asset Bundlesの注意点
- アプリを起動したUnityのバージョンと、Asset Bundles を作成したUnityのバージョンを揃えないといけない
- アプリ側のUnityをアップグレードした場合、Asset Bundles のデータも全てビルドしなおし
シーン分け
- Unityを使った共同開発ではシーンの競合が問題になる事が多い
- Ragdollでは開発初期から気をつけていたので、大きな問題にはならなかった
- シーンを読み込んだ時に、別のシーンを追加で読み込む機能がある
- プログラマが使うシーンに、アーティストのシーンを追加読み込みする
- EZGUIを導入後問題が発生
- EZGUIでアトラステクスチャを更新した際、別のシーンに配置しているEZGUIを使用しているPrefabのコンポーネント情報が更新されない
- アーティストによる更新が必要となる
- 手間の増大
- ヒューマンエラーの発生
- 対策
- アーティストはPrefabをシーンに置くのをやめる
- Prefabの用意までをアーティストの作業とする
- プログラマはシーンの追加読み込みではなく、Prefabを直に読み込むように変更
ライティング
- Unityはスマートフォンでは、シャドウマップをサポートしていない
- Blob Shadow Projector での丸影実装が現実的
- パフォーマンスも申し分ない
- Pixel Light Count の最適化
- ライティングの負荷が高い場合Pixel Light Count を減らす
- 大幅な処理負荷減
- Rag Dollでは、ノーマルマップの見え方の違いもほとんど影響なし
MayaからUnityへのデータ渡し
- FBXを選択
- Mayaがインストールされている必要がある
- Mayaからは.maファイルのインポートも選択出来るが、インポート時間がかかる
モデル・アニメーションデータの持ち方
- アニメーションデータにメッシュを持っていると、うまく行かなかった
- メッシュを付けず、Locatorをつけると解決できた
アニメーションデータの容量削減
- Unityに読み込んだアニメーションFBXは、アニメーションクリップだけ複製し抜き出す
- 抜き出した後のデータは削除する事で無駄なデータを省く事が出来る
※Gamewatchの記事のプレゼン資料が詳しいです
- データを更新する毎に上記作業をするのは面倒
- Asset Post Processorクラスの関数を利用し自動化した
Maya・Unity以外のツール
- パラメータの編集にExcelを使用
- プランナーはUnityを使用していなかったため
- プランナーがUnityを使う場合は、パラメータを拡張して使ってもらう方が良いと思う
- Unityだけで完結できるし
- バージョン管理はSubversion
- 1.6以前
- 各フォルダに隠しフォルダで管理フォルダが作られる
- Unity上でフォルダを複製すると、管理フォルダ毎に複製され不具合が発生する
- 1.7以降
- チェックアウトフォルダのみに管理フォルダが作られるようになった
- Unityでも使いやすくなった
Unity・Mayaへの要望（Ragdoll開発で感じた両ソフトの強化要望）
- 受け渡しフォーマットの強化
- Mayaから直接Unityで利用できるAssetの書き出し
- またUnityで利用しているAssetを、Mayaへインポートする機能
- Asset Bundlesのバージョン互換性
- Unityのバージョン違いでAsset Bundlesが読めない問題を解決
- Ragdoll開発中に何度か泣かされた
- 3.5から機能が拡張されたが、モバイルプラットフォームでは利用できない
Unityを使って良かったところ
- 開発力・チーム力の向上
- すぐに絵が出るので、レビューを受けやすくなった
- ゲームを見ながら、あーでもないこーでもないと意見を交わせる
- 実装までの速度UP
- コミュニティ
- コンシューマー開発環境に比べると、開発環境・ノウハウについての情報が多い
- FacebookのUnity助け合い所に業務中に書き込んで、解決する事もあった
Unityを使って良くなかったところ
- Unityで何でも出来るわけではない
- 自動化ゆえの不具合
- Unity自身の向き・不向き
- プロジェクトに必要な遊び・表現ができない事も
- お金を動かす人は「すぐできるんでしょ？」「お安く買えるんでしょ？」と言いがち
- それを開発側はそのまま受け入れるのではなく、やりたい事とUnityを使う事の相性は見極めないとダメ
- Ragdollでは早い・安い・うまいを全て達成できていない
- 特に早いに関しては達成できていない
- プロトタイプまでは早かった
- ただプロトタイプからリリースまでにはバグ対応・やりたい事が出来ないなど、いくつか障害があった
まとめ
- Unityは画材。作りたいものが明確でUnityに最適な内容であれば問題なく使っても良いと思う
以上。