Understanding groups & optimization

Hi there! I've got some confusion surrounding groups and how exactly they should be structured (or if it matters!)

1. Let's pretend for the sake of argument that organization for the sake of content updates and patches does not matter. Let's say I'm a god-programmer who makes a perfect product the first time and releases it once. In this scenario, does how I'm organizing my groups matter at all? For example, my understanding is that a single asset can be loaded without having to load the entire group. If that's true, would there be any reason to not just have everything in one massive group?
   • In fact, potential asset duplication would imply that one SHOULD in fact do that, right? All this is to say - the only reason why groups exist is to break content up so that patching and content updates are small and easy, right?
2. Along the same lines - if I have a duplicate dependency and I want to fix that, does it matter at all where I put that asset? Does it matter that it's in a new isolated group, or could it simply be placed anywhere?

Thanks to anyone who can enlighten me!

 

If you are packing your assets together when they are built, groups matter. If you are building all your assets separately, groups don't really matter, unless you want to apply different addressable settings to certain assets.

Fixing asset duplication, as long as those assets are addressable, it doesn't matter what group they are in, there will not be further duplication unless you have those assets built into the engine.

The only thing you may be concerned about is redirects. If you have all your assets bundled together, redirects are minimized. If they are all separate and you have deep nested dependencies, you may have a lot more redirects, causing longer load times. Of course, if you have everything bundled together and you only need 1 asset, you are potentially downloading much more than you really need. It's a balance that needs to be handled on a case-by-case basis.

 

Thanks for the reply!

... are you sure about that? I think I read a post on this form, from someone at Unity, who claimed that you can load an item from a compressed asset bundle without needing to load anything else.

Can you elaborate? If I'm packing my assets together, groups matter - why?

 

Sure, you may be able to load an item from a compressed bundle, but you still have to download that entire bundle.

Because it packs together by group. So if you have 2 groups and both of those are set to pack together, then you will get 2 bundles.

 

Oh interesting. huh. I guess for some reason I thought that it didn't need to load the entire bundle before loading individual objects from it.

Thanks for taking the time to reply!

 

Ah! more clarity. You mentioned the word "Download". I'm using addressables mostly for organization, and likely won't be doing a lot of downloading (also I'm also just trying to understand the system, that's why I started this thread with a hypothetical).

According to this gentleman:
https://answers.unity.com/questions/1422330/keeping-assetbundles-in-memory-vs-always-loading-f.html
"..assetbundles have a very low memory footprint (like a few kb each) compared to the assets that are loaded from it."

In other words, ignoring the download/distribution issue, it looks like it's slightly more performant to have fewer, larger bundles. Looks like there's a bit more to it than that though...

Found some similar questions asked here
https://forum.unity.com/threads/assetbundle-best-practices.511711/

 

Yes, the performance you get is all relative to your project setup. If all your assets are local or if you know you need a particular group of assets for a level, then large bundles makes more sense. On the flip, if all your assets are remote and you need to load assets individually on-demand, then individual bundles makes more sense. Of course that gets even more complicated with dependencies and redirects.

So really, you just need to test to find what works best for your project.

 

Yeah, that makes sense. Thanks for helping me understand