2018-06-08

【Unity】ドット絵に照明効果を追加する

今回はドット絵にライティングを追加するアプローチについてです。

f:id:tsubaki_t1:20180607221511g:plain

ドット絵　は　光の演出　を手に入れた！！！
感想
関連

ドット絵　は　光の演出　を手に入れた！！！

今回はドット絵に光の演出を試してみました。
例えば暗い洞窟や完全自動で動く工場など、ステージ全体が明るくない場所での表現において、光による演出は中々に楽しそうです。

なお、今回使用するのは殆どTilemapかSpriteRendererで構成されたものです。ライティングを施さなければ大体こんな感じになります。

f:id:tsubaki_t1:20180608003039j:plain

この辺り通常の3Dであれば、この辺りは最初からうまい感じに表現してくれるのですが、ドット絵はあくまでも2Dのため、一工夫が必要になってきます。

さて、光表現は大きく分けて４つの要素が考えられます。

光の届く範囲が見える
光を向いてる面が明るくなる
光るパーツは暗闇でも明るく見える
光を遮り影ができる

この４つの要素を全て入れる事も可能かもしれませんが、手間とか色々な要素を考えて入れるかどうかを判断する必要があります。

光が届く範囲が明るくなるだけで良い

まず「光が届く範囲が明るくなる」…という考えです。スーパーニンテンドーのRPGのような物でよくある表現で、目的は「視界を狭めること」です。
やり方は二通りあって、一つ目はSpriteMaskのようなステンシルを使う方法、２つ目は普通にライティングの機能を使う方法です。

まずSpriteMaskの方法を考えてみます。

画面前面に黒いSpriteを描画します。この時、Mask InteractionはVisible Outside Mask（マスクの外側だけ表示）に設定しておきます。
GameObject > ２D Object > SpriteMask で光の形状のスプライトをマスクに登録すれば、マスクの範囲がくり抜かれます。

マスクの形は変形しないので若干雑な感じの切り抜きに見えるかもしれませんが、個人的には暗闇表現なら大抵はコレで良い気もします。

f:id:tsubaki_t1:20180608000451g:plain

普通にライティングを利用する方法は、Spriteに使用するシェーダーを変更します。Spriteが光の影響を受けないのは、光の影響を受けない（代わりに高速）シェーダーを使っているからなので、コレを変更してやればOKという話です。

DiffuseSpriteという名前のMaterialを作る
DiffuseSpriteのシェーダーはSprite>Diffuseにする
TilemapRendererやSpriteRendererのMaterialをDiffuseSpriteに変更する
ポイントライトやスポットライトを適当に配置

これで光の陰影をピクセルベースで計算したものを使用できます。

f:id:tsubaki_t1:20180608001355g:plain

光の陰影や光るパーツなどを表現するのも欲しい

光の陰影や光るパーツなどを表現してみます。

なお光の陰影が追加される事で光の演出とテクスチャの光表現が重複する可能性があることには注意する必要があります。
（Unityゲームでよく見た「残念な感じの絵」の一つは、テクスチャに光表現を焼き込んだ上でシェーダーでも光表現を…という物があります）

f:id:tsubaki_t1:20180608005117j:plain

まず考えることは、陰影を2Dであるドット絵で表現する方法です。
これにはノーマルマップ（法線マップ）やエミッションなど表現に対応したテクスチャ用意します。
なおエミッションは全体を暗くして光らせたい所に色を付ければ良いのですが、ノーマルマップの方はどうやって作ればよいのか…

RGB のカラー値は X,Y,Z のベクトルの方向を保存するために使われます。Z が“上方向”になります(逆に、Unity では慣例的に Y が“上”)。加えて、テクスチャの Z 値は、0.5 が足されて半分になります。これは、すべての向きのベクトルを保存するためです。そのため、RGB カラーをベクトル方向に変換するには、2 倍してから 1 をひかなくてはなりません。

法線マップ（Normal Map）（Bump mapping） - Unity マニュアル

f:id:tsubaki_t1:20180608084842j:plain

あとはノーマル（法線）マップに対応したシェーダー…例えばStandardShaderなどをセットしたマテリアルを用意し、NormalやEmissionに設定、SpriteRendererやTIlemapRendererに登録すれば、光の表現が出来るようになります。

f:id:tsubaki_t1:20180608084444j:plain

Want to add cool lighting effects to your 2D sprites? Simple apply a material with normals (and whatever else you want) to your Sprite Renderer. Works with Tilemaps too! #UnityTips #Unity3D #GameDev pic.twitter.com/TnGr06NPIh
— Mike Geig (@mikegeig) May 29, 2018

なおSpriteRendererもTilemapRendererも、メインのテクスチャはレンダラが使用したいものが自動でセットされ、そのUVを使用してノーマルもエミッションマップも設定されます。つまりノーマルマップとエミッションのマップのレイアウトはスプライトに使用したものと同一である必要があります。

この何が問題かといえば、SpriteAtlasのようにパッキング後のレイアウトが確定せずスプライトをレイアウトする機能を使用すると、ドット絵とノーマルマップのレイアウトがずれてしまう可能性があるという事です。

つまり、この手法を使用する場合はドット絵側でスプライトを詰めてやる必要があります。

ドット絵に影もつけたい

最後にドット絵に影を付けてみます。
この時の考え方は単純で、ドット絵の上に見えない影だけを落とすモデルを配置するという力技を使います。

建物の高さはCubeの高さで、実際3Dで見たらどの辺りに配置されてるのかな…的なものを見たら上手くいきます。
配置後CubeはのMeshRendererのCastShadowの設定をShadowOnlyに設定しておけばゲーム画面では表示されなくなります。

キャラクターの影くり抜きの場合、Cutoutシェーダーでキャラクターのシルエットにくり抜いた影を使うというアイディアもありますが、Spriteに対応してないのでその辺り保留
f:id:tsubaki_t1:20180608090301j:plain

ただ残念な事に、背景…というか地面にTilemapを使用している場合このアプローチは使えません。TilemapはRecieveShadowを無視するみたいです（例えスクリプトでONにしても、影対応シェーダーを使用しても効果はありませんでした）　
なので影の手法を使う場合はTilemap以外の方法で背景を表示する必要があります。上の図では背景は普通にQUADを使用しています。

f:id:tsubaki_t1:20180608091020g:plain

まぁ建物の構造を強調するための影という観点で言えば、２DDLのような2D影を使ったほうが良いかもしれません。

assetstore.unity.com

感想

ということで照明効果についてでした。

オールインワンで無条件で突っ込めるという感じでは無いので、用途によって分けました。必要に応じて追加していくのが良さそうです。

「Unityテストを完全に理解した」の動画とスライドが公開

f:id:tsubaki_t1:20180608093128j:plain

先日行われた「Unityテストを完全に理解した」の動画とスライドが公開されてました。

Unity テスト完全に理解した - connpass

動画

動画はこちら。動画では少しスライドが見にくいので、スライドは別に見るのをお薦め

www.youtube.com

各セッションのスライド

Unityでどのようにテストを導入していくか…という話です。

speakerdeck.com

SOLIDの設計について

speakerdeck.com

【Unity】ECSのメモリレイアウトとその周辺

今回はECS（Entity Component System）とはどういった機能かといった話について書いていこうと思います。
この情報はハッキリ言えば知らなくても問題ない情報なのですが、知っておくとECSを採用するべきケースや作り方に迷ったときに助けになるかもしれません。

なお、ECSの概念や使い方については、Unity 2018のEntity Component System（通称ECS）について（１）やUnity 2018のEntity Component System（通称ECS）について（２）で紹介しています。
実際の使い方イメージはECSで簡単なゲームを作ってみたので、その解説です。

メモリ転送速度がCPUのボトルネックになる世界
- オブジェクト指向はCPUに優しくない
- その名はデータ指向設計
UnityのECSはデータ指向設計
感想
参考リンクメモ

メモリ転送速度がCPUのボトルネックになる世界

ここ数年でCPUの性能は飛躍的に向上し、またマルチコア等の複数並列同時計算能力も手に入れました。それに対してメモリの速度はそこまで高速化しておらず、メモリの転送速度がCPU性能を引き出す上でのボトルネックになっている事が多々あります。

例えばメインメモリからデータをコアに渡す場合、その読み込みを行う間にコアでは200サイクル以上もの処理を行えます。もし処理が完了したならば、情報が届くまでの間は待ち時間が発生します。
この辺りのギャップを無くすため、大抵のCPUにはL1キャッシュやL2キャッシュといった高速な（しかし非常に小さい）キャッシュが存在します。このキャッシュに乗っている情報の取得は3～4サイクルと非常に短い時間で取得出来るので、毎回メインメモリから取得するのに比べて圧倒的に効率的です。

f:id:tsubaki_t1:20180605230619j:plain

また普通は必要なデータを1バイトずつ転送するのではなく64バイト程度のメモリを一気に転送します。1バイトずつ転送したり必要な分を抽出する手間よりも一気に転送してしまったほうが高速という形です。

このため、もし必要なデータが例え1バイトしかなくとも、63バイトの無関係なデータと共にロードされます。

f:id:tsubaki_t1:20180605231249j:plain

オブジェクト指向はCPUに優しくない

オブジェクト指向やコンポーネント指向は、オブジェクトに処理やデータを格納し、内部でデーややステートを制御するアプローチです。このオブジェクトは各々が独立しており、基本的に単体で完結出来るのが理想です。
またオブジェクト毎に独立した形でメモリに展開されており、参照という形で各々のオブジェクトにアクセス出来るようになっています。

この設計はメモリの空きを作らないという点や設計しやすい点で非常に優れているのですが、キャッシュという観点から見ると少し良くないです。
各オブジェクトはメモリ上に散らばる形で配置されるため、メインメモリからデータを取り出す時に何度もメインメモリから転送する事になります。

f:id:tsubaki_t1:20180605232441j:plain

なお正しくはオブジェクト指向が悪いというよりは、オブジェクト指向だと大量のデータを操作するときに効率が悪くなりやすいという話です。
なので、少ないオブジェクトだったらソコまで気にしなくても良いと自分は思います（そう言っても大抵は最終的にオブジェクトの量が増えることが多いのですが）

その名はデータ指向設計

キャッシュに優れた場合のメモリレイアウトはどういったものか？
簡単に言えば、データが固まっているものです。

1回64バイトで可能な限りデータをロードしてキャッシュに載せられれば、以降のデータ読み込みはL1キャッシュから行われるようになります。
これでコアの待ち時間が殆どなくCPUは効率的に処理を実行出来るようになります。

f:id:tsubaki_t1:20180605235806j:plain

これでアクセスが高速化出来る訳ですが、この高速化を十分に活用する為には一つの処理中に様々なデータにアクセスするのではなく、アクセス対象を決めて一気に処理してしまうのが効率的です。

これは並列処理した場合でも同様で、むしろデータ構造的に並列処理しやすいといったメリットもあります。

f:id:tsubaki_t1:20180606125316j:plain

このようなメモリレイアウトの設計やデータのアクセス方法に着目した設計をデータ指向設計と呼ばれます。

UnityのECSはデータ指向設計

UnityのECS（Entity Component System）はC#上で実装されたデータ指向設計（Data Oriented Design）です。

利用者側から見た場合、Entityとはコンテナです。EntityにComponentDataを追加したり削除する事で、Entityの振る舞いを作ることが出来るようになっています。
その点で見ると、Entity＝GameObjectでComponent=Monobehaviourといえるかもしれません。この見た目は人類に優しいです。

f:id:tsubaki_t1:20180605234712j:plain

実際には下のように、ComponentData毎の連続したデータでありEntityはタダのIDでしかありません。Entity2と要求すればA[2]とB[2]、C[2]に簡単にアクセス出来るという感じです。
この辺りはEntityManagerが管理してくれています。

f:id:tsubaki_t1:20180605234922j:plain

SystemはComponentDataの配列にアクセスします。
実際には後述するもう少し面倒な話があるのですが、何にしてもメモリはある程度まとまった所にあるので一気にキャッシュに乗せて一気に処理するといった事が可能になっています。

f:id:tsubaki_t1:20180605235141j:plain

アーキタイプとチャンク

ECSのメモリ管理の説明をする上で外せないのが、チャンクとアーキタイプの2つの要素です。基本的にEntityは任意のアーキタイプを持ち、特定のチャンクに格納されます。この辺りは混乱しますよね。えーと、

まずアーキタイプとはその名の通りEntityの雛形です。Entityはアーキタイプを元に作成します。またEntityのメモリレイアウト等もココに格納されています。

チャンクは実際にComponentDataを格納するメモリ空間を管理するものです。チャンクは必ずドレかのアーキタイプに所属していて、同じアーキタイプのEntityしか格納しないようになっています。
同じアーキタイプしか格納しないので、もしEntityにComponentDataを足したり減らしたりすると、Entityはアーキタイプが一致するチャンクへ移動します。

このチャンクですが１チャンク毎に64KByteの連続したメモリを確保します。ここで確保し利用するのはメモリはネイティブなメモリです。
メモリ確保後は確保したメモリを塗るだけでオブジェクトの増減が表現出来るのでかなり低コストに生成・削除が実現出来る訳です。
また64KByteを使い切ると、新しくチャンクを増やす形で対応します。

ComponentDataArrayは複数のチャンクを一つの配列に見せる

チャンクは複数のアーキタイプ・そして64KByte毎に生成されています。要するに、「特定の種類のComponentData」を扱いたい場合には飛び飛びになってしまっています。

この辺りを使いやすくしてくれているのがComponentDataArrayです。ComponentDataArrayは一見連続した配列のようなインターフェースを持っているのですが、実際にはチャンク毎の「ComponentDataのポインタ」と「要素の数」を持ったリストのようなものです。

要素を取得する場合、下のような処理が行われているっぽいです。

チャンクの先頭のComponentDataを取得
要素の分だけ横にズラしつつデータを取得
（連続してるのでキャッシュも効く
要素を読み終わったら次のチャンクへ（1へ戻る

似たような形でShardComponentDataArrayというものがありますが、こちらは少し異なります。

そもそもShardComponentDataは複数のEntityで一つのShardComponentDataを共有する機能です。そのため、チャンクの中に含まれるのはShardComponentDataの実体ではなくアクセス用の何か（たぶんハッシュ値）みたいです。
なおShardComponentDataを含めると値の種類毎にチャンクが分割されます。そのためユニークなShardComponentDataが大量に有る場合、効率が激減する可能性があるので注意が必要です。

何にせよ、ComponentDataArray系をunsafeで触ると面倒なことになるかもしれません。

ComponentGroupによるフィルタリング

ComponentGroupは特定のComponentDataArraをフィルタリングして特定のComponentDataを持つ物のみのリストを作ってくれる便利機能です。

一致する要素毎に繋いでリストにする感じと予想してますが果たして。

なおComponentGroupのタイミングはフレームの最初か最後らへんと聞きましたが果たして。普通にオブジェクトを足したタイミングでチェックしてる印象があるんですが、うーん。

ちなみにフィルタリングコストは結構安いらしいです。これならラベル用のComponentData（0バイトの構造体）とかも普通に使って良さそう。

チャンク単位の操作

ComponentDataArrayは内部でチャンクの切替えを行っています。これは簡単にアクセス出来る反面、チャンクを跨ぐような処理を行ったり（componentDataArray[i-1]等）何度もチャンクを舐める処理を行うと効率が悪化していきます。
（例えばfor文で同じComponentDataArrayを何度も最初から最後まで舐める等）

こういったケースではチャンク単位の操作を行うことで、比較的効率的な処理が実現出来ます。

tsubakit1.hateblo.jp

メモリのレイアウト

メモリは実際には下のようになっているらしいです。一つのチャンク（64k）に同数のComponentDataが入るように、レイアウトが調整されています。

このComponentData一つ一つはStructなので構造体の配列（AOS）です。現状ECSはこの形で動作しているみたいです。
ただSIMD等に全部お任せする場合の最大効率は配列の構造体（SOA）と呼ばれる形で、その形が使えるようになってほしい所もあります。

この辺りはC# Job SystemとNativeArrayの形で見ると、ComponentDataを分解して配列の構造体として再レイアウトするSOAやAOSOA利用オプションが付くっぽいです。
現状C# Job SystemではNativeArraySOAを使用するという形でSOAを使えそうですが、ECSで利用するオプションは不明（未定）です。

Systemの実行順はGroup様を見てる

ECSのSystemの実行順番ですが、Systemが要求するComponentGroupを見て、決定しているみたいです。内部的に依存関係グラフが作られてるとか何とか。
例えばデータの読み込み(ReadOnly)は書き込み(WriteOnly)が終わった後に呼ばれるといった具合です。これで「データを入力し、入力されたデータを使って何かをする」の流れを特に意識せずとも実現出来ています。

f:id:tsubaki_t1:20180606014523j:plain