I’m diving into Unity’s Addressables and got caught up with a couple of concerns I hope someone here can clear up. I’m using a **ScriptableObject** as an **AssetReference**, specifically the `AssetReferenceCustomLightmapData` I’ve created. It’s supposed to manage the lightmap data, which includes things like `Texture2D` arrays and `BakedLightProbsData`.
Here’s the tricky part: Do I need to group the actual data assets (like those `Texture2D` textures and the `BakedLightProbsData`) into an Addressables group, or can I just leave the `AssetReferenceCustomLightmapData` on its own? The `CustomLightmapData` holds everything together, and as far as I can tell, no other assets will be needing access to those textures or lightmap data. My gut tells me that since the `ScriptableObject` is the sole access point, I might not need any additional grouping. But Unity’s documentation can be a bit vague on those specifics, so I’d love some input from those who have done this before.
Also, when I load the lightmaps, I’ve noticed it takes about **0.94ms** and generates **34.0KB** of garbage. Upon release, it’s a bit better with **0.27ms** and **15.2KB** of garbage. I can’t help but wonder: could this be related to the line `var data = new LightmapData();` in my `ApplyLightmapData` method? I’m definitely conscious of garbage collection in Unity, and if that line is a culprit, should I be worried about it? Any tips on optimizing this, or am I just overthinking the overhead here?
I guess I’m just looking for some reassurance from the community—whether I’m on the right track or if I need to rethink my approach. Thanks for any details you can share!
It sounds like you’re diving into some pretty interesting stuff with Unity’s Addressables! Let’s break down your concerns.
Regarding your AssetReferenceCustomLightmapData and whether you need to group the actual data assets (like Texture2D arrays and BakedLightProbsData), it really depends on how you’re planning to use them. Since your ScriptableObject is the main access point and you mentioned that no other assets will need access to those textures or lightmap data, it seems like you could indeed leave it standalone. However, putting them in an Addressables group can make handling dependencies and loading them more organized and cleaner in the long run, especially if you plan to expand your project later.
As for the garbage generation and loading time you’re seeing, it’s great that you’re being cautious about garbage collection! The line
var data = new LightmapData();in your ApplyLightmapData method could definitely be the reason for some of that garbage. Every new instance creates a bit of garbage that the GC (Garbage Collector) has to deal with. One way to reduce garbage is to reuse the same LightmapData instance instead of creating a new one every time. You can create it once and then modify its properties as needed for each lightmap you apply.Optimizing for garbage collection can sometimes feel overwhelming, but you’re definitely on the right track by monitoring it. Tools like the Profiler can help you dive deeper to see what’s actually causing the spikes. Remember, a little bit of garbage isn’t the end of the world, especially if your game runs smoothly overall. Just keep an eye on it and tweak as needed.
In summary, you might not need the additional grouping for your assets since your ScriptableObject is handling it, but consider how your project might grow. And yes, try reusing instances when you can to minimize garbage. You’re doing great—keep experimenting, and you’ll figure it all out!
You typically only need to mark the main ScriptableObject (i.e., your
AssetReferenceCustomLightmapData) as an Addressable if it’s the single entry point and directly references the dependent assets likeTexture2DorBakedLightProbsData. Unity’s Addressables system automatically ensures all referenced dependencies are included and bundled appropriately. Therefore, explicitly putting each texture or baked data asset into its own Addressables group isn’t necessary unless you explicitly want finer control over loading strategies or asset organization. Thus, recognizing your use case—since your custom ScriptableObject acts as the sole access point to all the related lightmap data—you’re correct: it’s sufficient (and typically cleaner) to address just the parent asset and let Unity handle dependency referencing automatically.Regarding garbage collection overhead, instances such as
var data = new LightmapData();are indeed likely contributing to the GC allocations you’ve noticed during loading/unloading phases. While 0.94ms and 34KB on loading, and 0.27ms with 15.2KB upon release, is relatively minor overhead in many scenarios, repeated garbage allocations can be troublesome if performance-critical or if frequently repeated (especially in VR or mobile applications). Consider poolingLightmapDataobjects or reusing existing instances to minimize GC load. However, unless these operations are frequent or performance-critical, you’re likely overthinking this minor overhead. Profiling further and checking if these allocations occur repetitively or heavily at critical moments should clarify if optimization is indeed necessary.