unity-assetこんにちは。入れ子になったプレハブは、ビルド時に入れ子が全部展開されてるっぽい、というのがこの記事の結論です。あと追加でParticleSystemを使うとデータがデカいということもお伝えしておこうと思います。2018.4.6及び2018.4.11での話で、他でも同じかは確認しておりません。何の話?とあるステージクリア型のゲーム製品がありまして、各ステージをプレハブとして作っています。いざビルドしてみると、このステージのプレハブが妙にデカいのです。それこそロード時間が気になるほどに。最初に「結果」として書いたことがわかったわけです。アセットとしてのプレハブと、ビルド後のプレハブアセットとしてのプレハブのサイズは、入れ子にしても大きくなりません。ステージの.prefabファイルはあまり大きくなりません。ステージのプレハブのサイズは変わりません。考えてみれば当然です。中身をコピーして持っているわけではないからです。(もっとも現状子をいじると、親プレハブ全部に再インポートが走ります。何か事情があるようです)。現実にはビルドすると実際のGameObject数に比例してサイズが大きくなるように見えます。すれば、考えられるのは、「ビルド時に子を全部展開している(コピーしている)」ことでしょう。本当にそうか実験してみました。実験Githubに実験プロジェクトを置いておきました。やっていることは簡単です。0という名前のプレハブにキューブを一個置きます。回転するRotationというコンポーネントも足しておきました。次に、1というプレハブを作って、そこに0を2個ずらして配置します。2というプレハブを作って、そこに1を2個ずらして配置します。3に2を2個、4に3を2個、5に4を2個、という具合に、13まで作りました。7の構造はこんな感じです。いう具合にキューブの総数は倍々で増えていきます。k番が持つキューブの総数は2^k個で、13では8192個ですね。ビルドでも同じことをしてみます。ビルドした時にはビルド後サイズも見てみましょう。7kbロードはResources.Loadの所要時間(秒)です。System.DateTime.Nowの差分で測定しました。8からは倍々の感じで増えていますね。.prefabファイルの大きさはみんな同じです。GameObjectの数が他と違うからですね。倍々で増えていき、そしてビルドログに出てくるサイズも倍々になっています。ビルドはmacのIL2CPPです。いう話になるわけです。ビルド時に参照構造を全部展開してしまう、というのは理解できる実装です。いうのは、言われてみれば当たり前感があります。指数関数的に容量が増える恐れがあり、しかもそれに気づきにくいのです。それほど多くのGameObject数にはなりませんでした。GameObjectを増やすには手間がかかるからです。手間によって数が制限されます。大した手間をかけずに凄まじい数のGameObjectを出すことができます。1段につきわずか2個でも、13段あれば8192個にまで膨れ上がります。手で置いたGameObjectの数は50個にもなりません。以前に比べて「GameObjectを置きすぎて重い」という状況が起きやすくなった、と言えます。今回のケースなお、よく調べてみたところ、今回製品で遭遇したケースは入れ子かどうかはあまり関係ありませんでした。問題はParticleSystemです。これがParticleSystemで作られています。このParticleSystemのデータが信じられないほど大きいのです。一つ置くだけで、.prefabファイルの行数が5000行近く増えます。あの莫大な数のパラメータが全部書き込まれているからでしょう。ステージのデータが非常に大きくなってしまったわけです。「GameObject数に気をつけて作ろう」と言うのも現実的な方策とは思えません。非プログラマに実装や性能のことを気にしてもらうのは非効率なのです。初期化時にそれを元にして動的にInstantiateする、という策です。「どこに」「何を」置くか、をいじるのがメインになるでしょう。「プレハブの種類と位置と角度」だけをjsonか何かで記録するだけで足ります。その情報を元に、実行時にInstantiateするのです。少なくともビルド後サイズと、ロード時間は改善するでしょう。ゲームデザイナーの作業としては、「気にせずプレハブを置く」であるべきです。良いのではないかと思います。「問題にならない程度」の増加で済むことを期待したいところです。スパイクを軽減することもできるでしょう。いったことも可能なはずです。使い終わったものを取っておいて使い回すこともできます。ないかもしれず、総合的には処理も削減できるかもしれません。プレハブが大きいということはInstantiateも重いでしょう。それを動的に行えばゲーム中にスパイクが出ることになります。スパイクしてでも動的に追加、というのが妥当な実装に思えます。まとめ速度より容量に配慮してほしいなあ、という個人的な感想です。Instantiateが多少遅くなってでも、参照を保った形でプレハブデータをビルドしてほしいなあと。問題が起こらない限りやらないのです。これはさすがにもう限界なのでは?感がすごいですね。08:00入れ子(ネスト)になったプレハブのサイズについてTweet関連記事2019-10-17物理シミュレーションで紙吹雪エフェクトを作ってみた画面をクリックするとwebGLサンプルに飛びます。動画もあります...2019-10-07UnityEditorからスマホに直転送して確認したいこんにちは。画面写真をクリックするとWebGLビルドに飛びます。こんにちは...2019-04-08アセットバンドルの不満をなんぼか軽減するライブラリを作ってみたこんにちは。やるこんにちは!面白法人カヤックのごんです。(1)月別アーカイブ検索スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。