夏までにiPhone アプリつくってみっか!

趣味でiPhone/Androidアプリを開発し、日々勉強した事を書いています。オープンワールド系レースゲームをUnityで開発中です。

【Blender】できるだけローポリ目指して地形をモデリング(道路編)

開発中のオープンワールドレースゲームの地形の作成に取り掛かりました。

街、山、水場がバランス良く配置され見栄えのする地形を作りたいのですが、自分の想像だけではまともな地形を作れそうにありません。
なので、ちょっと手抜きをして現実にある地形を参考にモデルを作りたいと思います。

今回は、相模川を挟んで両岸に街が広がり、西にはそこそこ起伏がある、なかなか見栄えが良さそうな場所として神奈川県の厚木市、海老名市付近を選択しました。
まずはGoogle Mapでそのあたりを表示し、画面のスクリーンショットを撮影します。私はMacbook Pro Retinaの15インチを使っているのですが、画面の解像度を1920 x 1200ピクセルに設定しておくと広い範囲を良い解像度で撮ることができます。

次に、主要な道路の向きが東西南北を正確に向くように画像を回転させます。
Macのプレビューアプリでは残念ながら90度単位でしか回転できません。
Clip Studio Paint Proでも試してみました。こちらは1度単位で回転できますが、ぴったり東西南北に合わせることはできませんでした。
ググってみたところ、Macの写真アプリのトリミング機能で無段階に回すことができるらしいので早速グリグリ回してみました。
こんな感じでグリッドが表示されるので道路の向きをぴったり合わせることができます。
f:id:takujidev:20151219220232j:plain

Blenderにその画像を取り込み、適当なPlaneにテクスチャとして貼り付けます。
Planeのサイズは画像の解像度の3396 x 1958に合わせてみました。つまり、Blender(=Unity)では約3.4km x 2kmのサイズとなります。
実は、これは本物の地形よりはかなり小さめになります。
地図上の500mの表示が210ピクセルに相当していましたので、実物の約2/5に縮小された地形がゲーム内に再現されることになります。
実物大にしてしまうと、実際の街と同じだけの建物のモデルを配置する必要がありこれからの作業がものすごく大変になってしまうので、2/5はなかなか妥当な値ではないでしょうか?

あとは、このPlaneの少し上に道路用のPlaneを別オブジェクトで配置していきます。1mくらいは浮かしておかないと縮小表示すると計算誤差でポリゴンが重なり表示がおかしくなります。

あと、Nで表示されるパネルのClip設定のEndの値を大きくして遠くまで表示されるようにしておきます。

Planeを伸ばしたり回転させたりしてとりあえずここまで道路を貼りました。

まだまだ先は長いです。
f:id:takujidev:20151219222424j:plain

Planeが交差する部分はこのようにして地道に接続しています。

1. 接続する前
f:id:takujidev:20151219222851j:plain

2. ナイフツール(K)で交差点の周囲4箇所を切る、
f:id:takujidev:20151219223115j:plain

3. 切断して作ったエッジをGGでスライドして交差部分にぴったり重ねる。
f:id:takujidev:20151219223304j:plain

4. Remove Doublesで合体させる。Merge Distanceは大きめに設定しておく。
f:id:takujidev:20151219223712j:plain

"Removed 4 Vertices"と表示されれば成功なのですが、結構な確率で失敗して合体しない頂点があるのが悩みです。ダメだった頂点を選択し直して再度Mergeするとたいてい成功するので、「まあ良し」としていますが。

この作業ををすべての交差点でやるのはかなり時間がかかります。
2つの面の部分重なった部分を結合するもっと効率の良い方法があればいいのですが、今のところいい方法は見つかっていません。

ところで、タイトルに「できるだけローポリ」と書いたものの、最終的にどの程度のポリゴン数になるのかまだ先は見えていません。
ポリゴン数を減らしつつもできるだけ良い感じに見える地形を目指しています。

https://itunes.apple.com/jp/app/toraberushutingu-retorona/id917570972?mt=8&uo=4&at=10laCt
https://itunes.apple.com/jp/app/beecluster-wu-liaono-zongsukurorushutingugemu/id663801586?mt=8&uo=4&at=10laCt

【Unity, Blender】軽くてデータ量の小さな街を作る

これまでゼンリンのJapanese Otaku Cityという、秋葉原をモデルにした街をベースにレースゲームを作ってきましたが、自分の街を作ることにしました!

建物のモデリングが90個くらい完成したので適当に並べてみたのがこれです。
植物の緑が一切ないので殺風景ですね。

f:id:takujidev:20151213144039j:plain

現時点ではJapanese Otaku Cityの地面を流用していますが、いずれは地形も自分で作る予定です。

Japanese Otaku Cityはかなりのデータ量、かつマテリアルをふんだんに使用しているため、モバイル用としてはなかなか厳しいものがあります。
もちろん、これを使ったiOS用ゲームはレースゲームも含めたくさん出ていますので使い方、用途次第だと思いますが、私のゲームではJapanese Otaku Cityの使用を諦め、自分で街を作ることにしました。
マテリアル(=テクスチャ)の使用をできるだけ少なくしてBatches, Setpass callsを低く抑えるのが目的です。

Japanese Otaku Cityを使った場合、UnityエディタのStats画面のBatchesが2728, Setpass callsが2264とかなりの値になっています。Graphicsのフレームレートは55.2fpsです。
なお、リアルタイムリフレクションはモバイルでは重すぎるので切っていてこの状態です。

f:id:takujidev:20151213140508j:plain

これは街を構成するビル各々が複数のマテリアルを使っているためだと思います。
例えば、こんなシンプルな四角いビルでも贅沢に5つのマテリアルを使用しています。

f:id:takujidev:20151213141555j:plain

そこで、今回はJapanese Otaku Cityのテクスチャを切り貼りして2048 x 2048ピクセルのテクスチャを1つだけ作り、街のすべてのビルが同じマテリアル、テクスチャを共有するようにしてみました。

f:id:takujidev:20151213142402j:plain

なお、Japanese Otaku Cityは「クリエイティブ・コモンズ 表示 4.0 国際 ライセンス(CC-BY)」で提供されていますので、クレジット表示さえしておけば改変などは自由とのことなのでありがたく使わせてもらっています。

さて、先ほどと同じようなシンプルな四角いビルですが、使用しているマテリアルは一つです。他のビルもすべて同じマテリアルを参照しています。なお、モデリングにはBlenderを使用しています。

Japanese Otaku Cityでは2階以上の部分を1つのポリゴンにし、窓1つ分のテクスチャーをリピートして貼り付ける構造のようです。この方法だとポリゴン数とテクスチャの面積は少なくて済みますが、大きなテクスチャの一部分をリピートしてポリゴンに貼り付けることは(たぶん)できないので、小さなテクスチャを独立して持つ必要があるのだと思います。

私の場合は階を積み重ねるようにポリゴンを構成し、階単位でテクスチャを貼るようにしています。大抵のビルは2階から上は同じ見た目なので、テクスチャの同じ部分を参照しています。また、幅の広いビルでは階ごとに1つのテクスチャだと窓が左右に伸びておかしく見えるので適当に縦方向にも分割する必要があります。

f:id:takujidev:20151213153029j:plain

また、1つの連続したメッシュにすることにはこだわっていません。ヘリポートやエレベーター部分の出っ張りなどの付加的な部分は別のメッシュを後づけしています。
こうするとモデリングやUV編集が楽でポリゴン数も減らせます。
パフォーマンス的にはどうなんでしょう?若干無駄な描画ピクセルが増えるデメリットがあるかもしれません。
なお、できるだけ見えない面は削除するようにはしています。

いろいろググってみましたが、「1つの連続したメッシュvs複数の別れたメッシュ」についてどちらがより適切な方法なのか結論は出ませんでした。
YouTubeチュートリアルで、「ドアに取っ手を作ろう」と言ってビル全体をぐるっと何箇所も輪切りにしているやり方も見たりしたので、作り方は人それぞれなのだと思います。

さて、冒頭のスクリーンショットで紹介した「俺の街」で早速車を走らせてパフォーマンスを確認してみましょう。

f:id:takujidev:20151213152933j:plain

Batchesが245、Setpass callsが62と大幅にダウンしています。
おかげでフレームレートが201.7fpsとなり、元の約4倍に向上しています。

もちろん、まだ木もガードレールも何もないビルだけのシンプルな街なのでJapanese Otaku Cityとフレームレートを直接比較するのは不公平ですが、マテリアルを減らすことでBatchesやSetpass callsの数を大幅に削減できることが検証できました。

ちなみにiPhone5上で実行した時のフレームレートは次のとおりです。

Japanese Otaku City: 14 - 15 fps
俺City: 37-38fps

なお、ビルド時のログに表示されるテクスチャサイズは40.7MB → 9.4MBに削減されましたが、ちゃんとした街を作るのにあと2〜3枚はテクスチャが必要なので、数MBは増加予定です。
ちなみに、Unityに取り込んだBlenderのモデルのサイズはシンプルなもので11KB, 複雑なもので47KBでした。ポリゴン(Tris)数はそれぞれ20, 470となっています。

試しにCR-Xで街を流してみました。

ご覧のとおり、メインストリートを外れるとただの空き地が広がっています。
他のビルに隠れて見えない部分はオクルージョンカリングで非表示になるので、マップをビルで埋め尽くしたとしてもfpsは下がらないと思います。

https://itunes.apple.com/jp/app/toraberushutingu-retorona/id917570972?mt=8&uo=4&at=10laCt
https://itunes.apple.com/jp/app/beecluster-wu-liaono-zongsukurorushutingugemu/id663801586?mt=8&uo=4&at=10laCt