Related Addressable Asset packing

Been using the addressables system for a project of ours and we have run into the following scenario that I have not found a good solution for yet:

We have a big asset group that is in Pack Separately mode.
It contains hundreds of mostly independent assets.
Some of these assets share enough dependencies that they really should be packed together in an asset bundle. For example, imagine an item that's available in multiple colours. All the versions have the same textures.
The way that packed separately works right now, their dependencies are duplicated. Obviously I have extracted dependencies that are common to the whole group into a separate group but this is not scalable to this use case.

Some Asset Group
-- Asset 1
---- Texture 1
-- Asset 2
---- Texture 2
-- Asset 3
---- Texture 3
---- Some data
-- Asset 4
---- Texture 3
---- Some other data
Common Asset Group
-- Dependencies of all of the above assets.

We would basically like assets 3 and 4 to be in the same bundle. If we were to split them off into their own group, it would take hundreds of groups which would be a nightmare to maintain.

This would be solved by putting related addressable assets in a directory and adding the directory itself to the group, but it does not seem to be possible to set the addresses of those assets like that.

What is the recommended workflow for this scenario?

 

If asset bundles are not compressed the good idea is to packed all the textures into the one bundle or separated bundles with textures only depends on the texture name like
textures_a
aa_texture,
animate_something_texture
textures_b
bb_texture,
bad_texture_of_something..

It is easy to put all the asset types into the alphabetically separated bundles
textures_a
textures_b...

sprites_a
sprites_b..

That is why I asked for addressable api to put asset in a group from code.
When you are loading assetbundle like addressables do it loads only a group header, not all the assets from the bundle.
If bundles and assets are well named like for example all the "forest style" assets names starts from "forest_..." than your bundles will be well grouped.

Anyway be careful with loading assets with materials because addressables does not unloading loaded textures even if these textures are in the bundle too. You can check it in memory snapshot from profiler. I hope it will be fixed soon, these textures keep fake-non longer existing reference to unloaded assets.

 

The problem is, these bundles are remote and individually dynamically updated on the server, so neither manual dependency management nor downloading megabundles that span multiple asset types is really an option, at that point we might as well write the whole system from scratch rather than use addressables. Right now, the dependencies are very well contained and easy to reason about without the extra layer of book keeping of what asset depends on what bundle.

For example, say we have a t-shirt in the game and it's available in three colours, all textures are common to all of them so it should be possible to put all of them in one bundle without the need to have a separate group for just them (considering that there are hundreds of different assets, each one with variants). As it stands, the bundles pull their dependencies automatically just by marking them as addressable without any extra work and are downloaded on demand with no need to pull extra data for other assets which is a great time saver.

The code is open anyway, you can modify it to add an API for this instead of waiting for them. My feeling is, however, that these (i.e. both mine and yours) are all use cases that should be supported out of the box, they do not seem to be far fetched at all.

That adds an extra level of manual asset management that should be unnecessary. In other words, the system seems to be 99% there, so reverting to what to me feels like the old asset bundle workflow for the last 1% does not seem to be in the spirit of the new system, hence the post here.

Hm, I'll have a profile and see if our particular use is affected by that. We had out of memory crashes due to textures not being unloaded *before* migrating to the addressables system and assset bundles and our memory usage has dropped dramatically since.

 

I think the "Analyze" button is the official recommended approach for this. The description seems exactly like your case. (i.e. the solution is scalable as long as you press the button every time manually)

 

I’m going to have a look tomorrow but I was under the impression that that is basically a refactoring of “extract common assets” from 0.3.x, which puts all common deps from everything into one group.

I feel separate groups really isn’t a scalable solution here, imagine keeping the group settings up to date when you end up with 1000 groups.

The lack of any sort of comment from Unity here leads me to believe that this is something I may need to implement myself but the rapid development of the system right now would make it tricky to merge changes from the baseline back in.

Edit: Any comment @unity_bill?

 

There are a couple solutions here, but all require some custom code or manual effort, and not all are fully ready in 0.4...

1. use the 0.4 "analyze" feature to find duplicate dependencies and pull them out into a common group. This is a heavy brute force method that would admittedly require a good bit of manual effort from you afterwards (to rearrange as needed).
2. Create your own rule to do the removal of duplicates in a smarter way. In the short term, you could do this by finding our code and editing that rule file. In the longer term, you will be able to create your own rules.
3. customize the build that processes your groups to pull out duplicates automatically at build time. This again is doable now, but will be easier in the future. Today, you can get our "packed mode" build script, and create your own version of it. Essentially our analyze code does a partial build, looks at the results, and goes from there. So you could take a look at both code bases, and potentially make your own build. The warning here is that we are changing how the build scripts work eventually (most likely in the first half of next year).

Long-long term, we'd like this to be automatically dealt with by the system. Or at least be super simple for you to code up yourself.

-Bill

 

I like idea 3 and I will look into that, I think. I do however wonder if there would be scope in the system for allowing more control over how the assets in a group as split into bundles is made, beyond Pack Together and Pack Separately.

For example, say we have a wearable group and in it we have a type of t-shirt which is available in multiple colours. If all of the prefabs could be put into one folder and that folder could be marked so that all of the addressables inside it are packed together along with their dependencies, even though the group itself is in Pack Separately mode, that would also work well. Functionally, it would be similar to them being in their own group but without the administrative overhead that entails.

 

Of note, the "pack separately" option only separates at the highest level. So if you marked a bunch of folders as addressable, you would currently end up with one bundle per folder. We haven't advertised this feature much because as I said, we're hoping to make this much cleaner/smarter/easier in the future.

 

Yeah, did notice that, the only issue for me was the inability to set addresses on the stuff contained in the folders, so if any future development takes care of that, it would be a great help!

 

We are looking into some options to improve that workflow.