I’m diving into developing a mobile game in Unity with a day-night cycle, and I’ve run into some challenges with managing my lightmaps efficiently. I’ve got a system in place that bakes lightmaps throughout the day, and I’m hoping to really optimize things by increasing the number to 48, so I’m looking at updating the lighting every 30 minutes. Each lightmap is around 426KB, so the total will be roughly 19MB, which isn’t huge but still something to keep an eye on for mobile devices.
I want the tool that handles lightmaps to be user-friendly, meaning users can modify them easily, but I also need a robust memory management system. I’ve been thinking about using Addressables to load and release these lightmaps efficiently. My idea is to group the lightmap data—textures and baked light probes—into a ScriptableObject. This would be marked as Addressable, and users would access lightmaps solely through this ScriptableObject.
Here’s where I get stuck. First off, does this solution make sense, or is there a better way to go about it? I’m also curious about the memory aspect: if I store lightmap data in the private array `_lightmaps`, will it stay in memory until I manually release it? Is there a certain way I should go about releasing the lightmap ScriptableObject from memory?
Lastly, I’ve been toying with different strategies for loading lightmaps. One option is to load a certain number of lightmaps in batches, releasing them immediately once they are no longer needed. Another idea is to load multiple lightmaps at once and release them all together after use. What do you guys think would work best for my system?
I appreciate any insights or suggestions you might have!
Optimizing Lightmaps for Your Mobile Game
Sounds like you’re on the right track with your day-night cycle and lightmap management! Using Addressables for your lightmaps is a good idea, as it allows for more flexible loading and unloading, which is crucial for mobile performance.
About Your Current Approach
Your plan to group lightmap data in a
ScriptableObject
is solid. This way, you can easily manage and modify your lightmaps. Just remember, when you mark it as Addressable, it’ll help with loading/unloading, but you still need to handle the memory part carefully.Memory Management
Regarding your question about the private array
_lightmaps
: yes, if it’s holding references to your lightmaps and you don’t release them, they’ll stay in memory. To release the lightmapScriptableObject
, you should callAddressables.Release
on it when you’re done using it. This will free up the memory in a more efficient way.Loading Strategies
As for loading strategies, both of your ideas have merit! Here are a couple of thoughts:
Recommendation
It might be beneficial to start with the batch loading approach as it provides a good balance between preloading assets and memory management. As you get more comfortable, you can experiment with the bulk loading.
Lastly, always keep an eye on performance and memory usage, especially on mobile devices. Profiling tools can help you figure out what works best for your game. Good luck with your project!
Your approach of using a ScriptableObject marked as Addressable to encapsulate grouped lightmap data (textures and baked probes) is sound and aligns well with Unity’s recommended practices for managing dynamic assets efficiently. ScriptableObjects provide a clean, organized way of referencing related assets, and marking them as Addressable absolutely makes sense because it gives you granular control over asynchronous loading and unloading. Regarding memory management, storing your lightmap assets in a private array like
_lightmaps
means these references will indeed remain in memory until explicitly released. To manage memory effectively, you’ll need to call Addressables.Release() or Addressables.ReleaseInstance() on the loaded asset references once they’re no longer required. Be cautious about keeping lingering references to loaded assets in your arrays or variables, as this can prevent proper unloading from occurring.When it comes to your loading strategy, batching seems preferable. Given you’re targeting mobile platforms, it’s crucial to limit memory consumption consistently. Loading a small, predictable number of lightmaps at intervals, then releasing them immediately after they’re no longer needed, typically results in better memory efficiency than loading large groups at once. For example, as time progresses in your game’s day-night cycle, load only a small set of relevant lightmaps ahead of their current necessity, and unload those no longer relevant immediately afterward. Keep your batch size manageable to minimize loading overhead and avoid hitching. This incremental loading strategy ensures you maintain performance stability on mobile hardware while avoiding large memory spikes.