Difference between "Bundle Dependencies" and "Expanded Bundle Dependencies" in buildlayout.txt?

Unity Engine
,
1

The buildlayout.txt contains sections for Bundle Dependencies and Expanded Bundle Dependencies.

What’s the difference between them? What’s an “expanded” bundle dependency?

Archive r-level-metagame_assets_assets/scenes/metagame/content_a896343d0e652254a366918dc009d2f2.bundle (Size: 1.9MB, Compression: Lz4HC, Asset Bundle Object Size: 2.66KB)
    Bundle Dependencies: defaultlocalgroup_unitybuiltinshaders_ef4f4760a7f78f4f8bb2c5d0644f4c8c.bundle, lr-shaders_assets_assets/shaders/diffuse_0ec2c1ff425aab90bae7b7c79f964d1e.bundle, lr-shaders_assets_assets/shaders/skybox_d462d33dcf229743347514b3f7561b1f.bundle
    Expanded Bundle Dependencies: r-theme-shared_assets_assets_all_6f5ec336d1378dc9910d3b9871c4a2fb.bundle, lr-shaders_assets_assets/shaders/shaderforge_3b90b9f4ad2cef942e7b83e2df31fc6e.bundle, defaultlocalgroup_monoscripts_48eef9bf5ed5a3584cd1e8dd9725f4e1.bundle
1 Like
2

I’ll ping the team for some insight.

1 Like
3

Bundle dependencies should be the dependencies one layer deep, the expanded dependencies should just be the rest of the dependency tree in a flattened list.

So if A depends on B, C and C depends on D, E, F then Dependencies for A would just be B, C but the Expanded Dependencies for A would include D, E, F.

2 Likes
4

Thank you for the answer.

Your explanation makes perfect sense for me, but it’s somehow not what I see in the buildlayout file.

I tested it in a new project where I can test it in isolation, because in my actual project, it’s way too difficult to understand.

I created 4 Prefabs:

  • Prefab_A with a hard-reference to Prefab_B
  • Prefab_B with a hard-reference to Prefab_C
  • Prefab_C with a hard-reference to Prefab_D
  • Prefab_D has no reference

I created 4 bundles:

  • Bundle_A contains Prefab_A
  • Bundle_B contains Prefab_B
  • Bundle_C contains Prefab_C
  • Bundle_D contains Prefab_D

According to your reply, I assumed the dependencies for Bundle_A are:

Bundle Dependencies: bundle_b_assets_all.bundle
Expanded Bundle Dependencies: bundle_c_assets_all.bundle, bundle_d_assets_all.bundle

However, the dependencies are actually this:

Bundle Dependencies: bundle_c_assets_all.bundle, bundle_d_assets_all.bundle, bundle_b_assets_all.bundle
Expanded Bundle Dependencies:

Is this a bug or is my assumption wrong and I didn’t understand what you were saying? I’ve attached my test project in case you want to take a look at it.

7432052--910283--upload_2021-8-19_17-26-22.png

7432052–910286–test_project.zip (57.3 KB)
7432052–910289–buildlayout.txt (3.98 KB)

5

Maybe he meant transitive dependencies on an asset level, not on a bundle level? Trying maybe having some explicit entry in Bundle A reference an implicit entry in Bundle B (asset not directly added to group).

1 Like
6

Thanks for your reply. This lead me to do more trial&error.

I found what seems to cause something to become an “expanded dependency”. It’s complicated to describe, but let me try.

Prefab setup:

  • Prefab_A has a hard-reference to Prefab_B

  • Unused_A has a hard-reference to Sprite_A

  • Unused_B has a hard-reference to Sprite_B

Bundles:

  • Bundle_A contains Prefab_A and Unused_A

  • Bundle_B contains Prefab_B and Unused_B

  • Bundle_Sprite_A contains Sprite_A

  • Bundle_Sprite_B contains Sprite_B

The prefabs Unused_A and Unused_B are not referenced, but they are stored in a bundle that contains an asset that is referenced and thus pull in an “expanded dependency” to their assets stored in another bundle.

Bundle_A has these dependencies:

Bundle Dependencies: bundle_b_assets_all.bundle, bundle_sprite_a_assets_all.bundle
Expanded Bundle Dependencies: bundle_sprite_b_assets_all.bundle

It seems the “expanded dependencies” list represents bundles whose assets are not referenced by the entire dependency chain of any explicit asset in the bundle, but are pulled in because they are dependencies of non-referenced assets in the same bundle.

However, this behavior is not what @davidla_unity described in my opinion.

7433795–910688–buildlayout.txt (8.47 KB)
7433795–910697–test_project.zip (84.3 KB)

1 Like
7

Based on what I see in buildlayout of my project, it looks to be fairly accurate. I’ll try to put it this way:

  • If any of the explicit or implicit entries in the Bundle A have hard references to entries in Bundle B, then Bundle B is a “direct” bundle dependency.
  • If, in turn, Bundle B has a direct bundle dependency to Bundle C, but Bundle A is not dependent on Bundle C directly, then Bundle C will be an “Expanded” bundle dependency on Bundle A.

This explains your first experiment. Because you had a long chain of hard references between your prefabs, to load the Prefab A in memory you need to load all other bundles, because they have required asset-level dependencies. However in the second example, to load Prefab A you only need Bundle B (which contains Prefab B), but you don’t need Unused A/B. So there is no direct bundle dependency. But if you were to load Unused B by it’s address, Unity will require both Bundle B and Bundle_Sprite_B to be loaded in order to do that. So it makes sense to load both direct and expanded dependencies before you can load anything.

So in the end I think @davidla_unity description was accurate. If you first calculate direct dependencies between bundles based on asset dependency graph, and then consider the result on a bundle-level, it all makes sense. Expanded dependencies are transitive dependencies on bundle-level, not asset-level.

8

I have way too many expanded dependencies for my bundles. If the theory is right, I should end up with the same list of bundles as the expanded dependencies by walking through the direct dependencies and noting down every bundle I encounter. But that list is much smaller (like, 5 bundles instead of 200) than the expanded dependencies suggest.