シーンを読んだりしている内に面白いことに気づいた。
「同じリソースを続けて読んでいる時は、ロード時間が極端に短い」
シーンの読み込みは、元のシーンを一旦破棄しているはず。
なので、これはおかしい。
■次のシーンに同一マテリアルがあれば読み込まない
なので、少々実験してみた。
シーンを3つ用意し、それぞれの往復時間を計測する。
シーンA:何もないシーン
シーンB:大量のマテリアルを含むシーン
シーンC:シーンBと同一のマテリアルを使用するシーン
(座標は変えてある)
で、実際に移動してみた感じ、こんな感じになった。
シーンA -(約4秒)→ シーンB
シーンA -(約4秒)→ シーンC
シーンB -(1秒未満)→ シーンC
シーンC -(1秒未満)→ シーンB
シーンC -(1秒未満)→ シーンA
シーンB -(1秒未満)→ シーンA
シーンB -(1秒未満)→ シーンA-(約4秒)→シーンC
シーンC -(1秒未満)→ シーンA-(約4秒)→シーンBシーンB -(1秒未満)→ シーンA-(約4秒)→シーンB
シーンC -(1秒未満)→ シーンA-(約4秒)→シーンC
この動作から察するに、どうも次のシーンと同一のマテリアルがあれば、
ロードは行わずに使いまわすらしい。
が、シーンに無ければ容赦なく削除・初期化をかける。
なのでシーンAを挟むとロード時間が伸びるみたい。
■参照があればロードしない
となると、もう一つ気になることがある。
キャッシュしてあるマテリアルは読み込むのかどうかについて。
なので、シーンBに使用するマテリアルをキャッシュする仕組みを登録して、
動作を確認してみたところ、
Bのマテリアルが開放されずロード時間が大幅に短縮された。
シーンB -(1秒未満)→ シーンA-(1秒未満)→シーンB
シーンB -(1秒未満)→ シーンA-(1秒未満)→シーンC
シーンC -(1秒未満)→ シーンA-(約4秒)→シーンB
シーンC -(1秒未満)→ シーンA-(約4秒)→シーンC
メモリ不足にならないのであれば、UIやテクスチャ等の
よく使うマテリアルをキャッシュ化しておけば、
ロード時間が大幅短縮できると思う。
これで1シーンに拘らなくても良くなれば良いけど(´・ω・`)