Unityエディターとビルド後のメモリについて(素人目線とAI)

unity技術

ゲーム開発・ゲームプレイにおいて「メモリ」の使用量を気にしておくことは重要である。
と聞きかじったことがあります。

メモリ使用が貯まっていくと、動作不良バグ原因挙動不審などの症状に見舞われるから、
タイミングをみて「メモリ解放」をしておくのが良いとのことでした。

Unity作業中に、使用メモリを見たらUnityだけで2G使用していたので、メモリのことをふと思い出し、
AIエディター使用メモリとビルド後のアプリ使用メモリに関して聞いてみました。

Unity6URPにおけるメモリ削減は新規プロジェクト、メモリ使用量の軽減【Unity6】でも行っています。

    Unityエディターの使用メモリを抑えたい

    開発中のゲームを「ノベルゲーム」としましたが、
    実際は2.5Dの3Dも使用するものなので、最初からさらに詳しく開発状況を書いておくべきでした。
    なんとなくは伝えているのでそのままの答えを見ていきます。

    現状では、3Dモデルの部屋複数家具をそのまますべて配置して作業をしていました。
    Blockbenchでのテクスチャもモデル毎だったりして数もあります。
    ライティングも3つのライトを常時点灯させている状態です。

    別事案を聞いたときに、モデルやテクスチャの重さが軽くても関係なし、読み込む数による、みたいな回答もありました。
    やはり「テクスチャ」を見直してみた方が良さそうです。
    サイズを小さくし(512px以下)、複数モデルのテクスチャを1つにして、読み込み数を減らす方法をと考えています。

    2.5Dのこだわりをもう少し伝えておくべきでした。
    あとは、カメラで映らない物まで配置しっぱなしなので、そこを気にしてみようと思います。
    2Dスプライトに関しては、とにあえずほっておいて良さそうですね。

    テキスチャやキャラクターのPNGファイルは「TinyPNG」でサイズ圧縮はしています。
    かなり軽く変わるのでお勧めです。

    3Dと影は譲れない設定

    現開発のこだわり情報を追加して、3D部分について質問してみました。

    やはりBlockbenchでのテクスチャ貼りをすべて考え直して、やり直してみたほうが良さそうです。
    サイズはトッド絵で軽いので、を抑える方向で作成していきましょう。

    Unityエディターの使用メモリ解放タイミング

    とりあえず、ゲーム画面に映らない小物3Dモデルなどは「非アクティブ」にする方向でやってみます。
    ビルド後のメモリ使用量は、エディターよりも低いらしいので、それも覚えておきます。

    3D探索ゲームの場合の解決方法

    見せ方」の問題らしいので、常にプレイ画面を確認しつつ、映る物の優先順位を意識しておきます。

    ビルド後アプリのメモリ使用量

    繰り返しになりますが、Unityエディターでは諸々のメモリを使用しているので、アプリ状態とは同じにはならない
    エディターよりもアプリのほうが使用メモリは低くなることを覚えておきます。

    メモリ使用量の目標値

    もう少し詳しい条件で聞いたほうが良かったですが、とりあえず「800MB」付近を基準としておこうと思います。
    しかし低スぺPCで動作するのが理想なので、常に意識しながら下げていきたいところです。

    Profilerでの計測

    エディター=アプリではないと知りましたが、「Profiler」での計測結果はどうなのだろうかと質問しました。

    やはり「グラフィック」関連を重点的に気にしていけば良さそうです。

    Profilerでの計測結果を分析してもらう

    とはいえ「Profiler」の見方はド素人なので、分析をしてもらいました。

    テクスチャが894枚!?と思いましたが、3Dモデルの1つの面を1とカウントしてそうですね。
    メッシュの軽さに笑われていますが、これはほぼ四角形しか使用していないので狙い通りなのかもしれません。

    現段階でテクスチャなどの最適化をしていない状態での結果です。
    しかもまだノベルパートの1つだけであり、
    今後は「BGM」「効果音」などの音関連も入ってくるし、画面エフェクトなんかも追加するだろうしで、
    どんな結果になっていくのか分かりません。

    とにかくメモリを意識し続けていきましょう。

    Scene分けでのメモリ解放方法

    ノベルゲームエンジンで制作していた時も、場面変換などのタイミングでメモリ解放を差し込んでいました。
    同じような考え方で良いのかどうか聞いています。
    Sceneの移動をしていれば、特に専用のスクリプトを組む必要はなさそうですね。

    Scene間での素材の使いまわし

    PC負荷的・メモリ的に、使いまわし素材の再読み込みはどうなのか疑問に思って聞いてみました。

    3D背景は、常駐させている専用のSceneを作って、それを参照させるやり方があるということを学びました。
    やはり構築の発想は、Unityでも必要みたいですね。
    探索パートや第2第3のノベルパートが残っているので、常駐型を試してみたいと思います。

    あと気になったのが、メモリ解放でメモリがクリーンになることがメリットに挙がっていますが、
    常駐方法に関して別途質問したときは、メモリ解放を繰り返すことでフラグメンテーションも発生する、みたいなデメリットを挙げていました。納得できる部分ではあります。

    常駐型は「背景」だけに限らず、「UI」や「BGM」なんかもいけそうなので、
    共有する物をまとめて置いておく「共有Scene」を作る構築もアリな気がしてきました。
    しかし安全性もあるので、これはまた別で深堀していく必要がありそうです。

    AIと向き合っていると、疑問解決中に新たな疑問がわいてきて、作業の脱線がはかどります(*´ω`*)

    コメント