We have a game in production (on Steam) which makes extensive use of Addressables.
Over the last year the size of our content has grown and so we split it out into 3 separate groups. Each group contains a bunch of prefabs that are isolated (no materials or textures or other assets within those groups are shared with another group).
We’d like to be able to make a change to a prefab inside of 1 group and rebuild that without all of the other ones also getting rebuilt. Otherwise, each time we push an update our users are having to download 1GB of data again even though we only changed like 100kb.
Note: For the bundle file naming convention, we turned off the auto-generated hash file names because we wanted to keep a single consistent filename per bundle so it was easier to track inside of Git LFS.
I’m not sure if by “the other ones” you mean the other prefabs in that group, or you mean the other isolated groups. I think you mean the former, since the latter should already be working.
Unfortunately, that’s one of the drawbacks of that particular packing strategy. You can see more about bundle packing strategies here. One of the big limitations with AssetBundles (the engine system that Addressables is built on) is that they don’t support binary/delta patching.
Moving forward, you might consider breaking your large groups down into smaller ones that are defined by prefabs you think might be updated simultaneously. Initially this would still result in a large download for your users. Breaking a 1gb into 2 512mb bundles is going to require your users to download both, but in the future if something in 512mb bundle A gets updated, you only have to update that group/bundle instead of the full gig one. I’m not saying splitting your Groups down the middle is the solution, but it might be worth considering breaking down your groups now that the amount of Addressable content you have has grown so significantly. It’ll likely be a bit painful, but should improve your users experience overall in the long run.
Sorry, I meant the latter actually. We have 3 groups set up and even though I only changed 1 small thing in one of the prefabs in 1 of the groups, when I rebuild it is recreating the .bundle files for each group which ends up needing to be pushed to our Git repo and then to Steam for release (nearing 1GB of data each time).
Oh, interesting. So, something I’d be curious to know, if you go into Edit → Preferences → Addressables and turn on the Debug Build Layout toggle and do a build, what shows up as the bundle dependencies for each of your groups? It’s possible that there’s a dependency somewhere in the dependency tree of any of your assets that is causing that link without meaning to.
It could also be a shader issue. All your groups are likely going to have a dependency on the built in shader bundle. If something changes the built in shaders, that would cause everything to get re-built. It’s also possible you’re running into this: https://issuetracker.unity3d.com/is…lues-when-game-window-aspect-ratio-is-changed which should be fixed in 2020.3 LTS
Also is your content update build happening on machines with different hardware architecture? Due to floating point precision, we have seen issues where bundles are changing when built on different OS/hardware. That might be something to consider.
I’ve attached the TXT file for more details. Appreciate the help so far. You (and your team) have done an outstanding job on Addressables. We’d be at a huge loss without it!
Thank you! That means a lot, I’ll pass that along to the team.
So, this does prove that all your groups are independent of each other, so it’s not that.
One thing to check would be that the built-in shaders are getting changed. If you look at the dependency that all these bundles share, outfits_unitybuiltinshaders_5826a034fbf427dc376d31d5f68a79eb, I’d make a note of that hash at the end of the filename. When you do an updated build and it rebuilds everything, does this hash change? If it does, you might be running into a shader/editor bug.
I just took a quick glance through some of the implicit dependencies (assets not directly marked addressable but that get pulled into an AssetBundle) that each group has a I noticed this, Assets/Resources/StandardDoubleSidedV2.shader, appears to be shared across a few groups. It could be that this, or some other implicit dependency is getting changed somehow when an asset gets edited. I’d definitely look at the changing built-in shader bundle changing before I went down this path, it was just something I noticed that might link multiple groups to needing a re-build without meaning to.
So it doesn’t look like the hash is being changed for “outfits_unitybuiltinshaders_5826a034fbf427dc376d31d5f68a79eb” so that’s one less thing to worry about.
My apologies, it does indeed look like Addressables is only recreating the .bundle files for the groups that actually contain assets with changes. Your point on separate machines made me find a flaw where sometimes a single FBX mesh changed its filesize slightly based on the machine so that’s an issue on our side that needs fixing.
However, I noticed that all the .meta files for each .bundle (e.g. outfits_assets_all.bundle.meta) get deleted when a new addressables build is performed. These are then recreated only when doing a full Unity game build. After they get recreated, the GUID is different even if the corresponding .bundle file didn’t change. Perhaps this is a non-issue but I wanted to raise it nontheless.
Lastly, one of our groups contains about 20 “outfits” - these are prefabs that get instantiated for a characters clothing when in-game. When we add a new outfit to this group, but don’t change any of the existing ones, obviously the entire group bundle is getting recreated. Is there a smarter way to do this? Such as a single group for each outfit that only has 1 prefab inside? On paper that sounds weird to me but I want to try and avoid having people redownload 400mb of assets just because we added a new outfit.
Ah, I’m glad you were able to track that down. Those machine variant issues can be tricky.
I was unaware of the guid changing, that’s interesting. I’ll have to bring that up to the team, thanks for pointing it out.
So, for adding a single outfit I probably would create a new remote group for the outfit so your users only have to download the one, much smaller, bundle. If I were releasing brand new content, I’d package all the new stuff into a single group, I think. It’s always possible to consolidate groups later on, if it makes sense. I would kind of be careful about consolidating groups though as it’ll mean some dead bundles will live in your players cache for a while.
As far as it being weird, there are plenty of projects that do Pack Separately and/or have extremely small Groups. When taken to the extreme this can be problematic, so it’s not a perfect solution for everything. It mainly comes down to finding the right balance of large and small Groups/AssetBundles that works for your project. It sounds like your 3 to 4 larger groups works great, but you may need to have some small Groups to keep your content update size low.
I wasn’t aware of Pack Separately, thanks for the heads up.
We’re now using that for a couple of our groups and added labels for another. This helps to keep the total bundles size similar to what it was before but split into more bundles that will make releasing new content a smaller download for clients in future.
