cluster分割ロード実験

概要

clusterで分割ロード・サブシーンがつかえるようになったので、自ワールド「花街」を舞台に実験してみる。
今回はワールドの一番奥にある建物「大床」(アイテム以外)を対象としてやってみる。

サブシーン使用前の状況

容量は91MB。ここに関してはサブシーン使ってもワールド内使うものは全部cluster側にアップされるし、
テクスチャなどを変えるわけでもないので、特に変動に期待せず。

門入ったところで最高値
大床前

Statistics 自分のワールドの中でも最高値をたたき出している。なんとかしたい。

カリング状況→まあまあ普通並みに
メモリプロファイラ

門入ったあたりでのメモリ使用状況。このあたり、現状では大床のデータも読み込んでメモリ利用量あがっているので、分割ロードでの変位に期待。

環境によって変わるけど、参考までにcluster上の数値も撮っておく

ではサブシーンつくります

今回は単純にやります。
まず、サブシーンにしたいものをフォルダにひとまとめにします。(以降、サブ用フォルダと呼称)
今回で言えば「大床」内の床や壁などが対象となります。サブシーンにはUIやアイテムは置けないので、それらやスポーンなどはメインに残しますす。

マスターのシーンをバックアップでとっておき、複製を2回します。
①メインシーン:サブ用フォルダのみ削除
②サブシーン:サブ用フォルダ以外を削除。

メインでコライダー判定を入れる範囲。この範囲内ではサブが読み込まれる。

メインのほうにサブシーンのコンポーネントを入れます。
ポストプロセスと同じ感覚で、指定したコライダーの範囲内にいるときにサブシーンが読み込まれます。
今回、サブシーンコライダー(分割ロードされる位置)は「大床」から二個目の灯篭あたりにしてみました。

結果どうかな?

門の先 セットパス445→232 Verts1.7M→0.9M
176→219

サブシーンロード後はセットパス上がっちゃった感じ。この辺はうまくライトベイクをわけていかないとだめかも?2重になっている感じもある。

メモリは期待通り結構減った
2892→2640
分割ロード後。メインが残ったままなので、ここの数字に変化ないのは当然の結果

メモリの減り方は順調

91MB→15MB

なんてこった容量が激減した。ただこれはandroidのサブシーンの数値っぽい?そしてここは見かけ上の数字。

androidのサブの数字が出ている感じ?それは詐欺ではw

ロースペック機には影響大きいかも?

と、いうことで数字だけを見ると結構上々な出来である。
今回は制作済みのワールドを無理くり分離したが、最初から計画的に作れば効果的に負荷を下げられるのではないかと思う。

銀茶、レカさんご協力ありがとう

なお、分割ロードは自分にだけにしかきかないので、他の人がコライダー判定の場所に行ってもロードされません。誰かが行っても自分のメモリは変わらず。奥になにもない状態が見える。

気を付けないといけないと思ったこと

カメラを飛ばすとトリックが見える

サブシーンの読み込み開始はあくまでコライダー判定なので、カメラを飛ばすとロード前の部分が見えてしまう。
→ここのフォローがSubSceneSubstitutesでできるのかしら?

・アップロード後、再度プレビューするとセットパスが4桁、Vertsも異常値に!
こういう異常値なときはたいてい、インタラクティブなアイテムにstaticがついているかライトベイクされていないか、で
急に前者にかわることはあり得ないので、後者だ。
再度ライトベイクすることで元通りになったが、何度やってもclusterへのアップ後にライトベイクがリセットされてしまうようだ。
clusterではイベント中にワールド変更するとアバターが真っ黒になる現象があり、どうもライトプローブが悪さをしているのが原因らしいので
今回もそこな予感がする。あるいはなんらかバグか?

clusterはいって異常がない(この数値なら普通動かなくなる)ので、アップされたものは問題ないっぽいけれど、次アップする前に毎回ベイクが必要かもしれない。恐ろしや。この辺どなたか検証求む。

・サブシーンのMesh Collider効かないかも?
→要検証

結果的に、大きなワールドを作るために使える、というよりは負荷を減らすことができる(まあイコール大きなワールドづくりに便利ではあるが)というマイナスをなくす機能なのかな、という感触を受けた。
ただ普段からLODやカリングで負荷に努力している人にとってはだいぶ楽ちんになるのではないかと思う。複数サブシーンを使った際の挙動など、みなさんの報告に期待。

いいなと思ったら応援しよう!