Remove assets from Renderer's build about adr HOT 12 OPEN

Also according to Unity, Building Addressables can be a part of the build pipeline out of box:

Build Addressables on Player Build (Unity 2021.2+)

Determines whether Unity builds Addressables content as part of your Player build.

Building Addressables content together with the Player can be convenient, but does increase build time, especially on large projects, since this rebuilds the Addressables content even when you haven't modified any assets. If you don't change your Addressables content between most builds, consider disabling this option.

The options include:

Build Addressables content on Player Build: Always build Addressables content when building the Player.
Do not Build Addressables content on Player Build: Never build Addressables content when building the Player. (If you modify Addressables content, you must rebuild it manually before building the Player.)
Use global Settings (stored in preferences): Use the value specified in the Unity Editor Preferences (under Addressables). This option allows every project contributor to set the option as they choose.

from adr.

Awesome!

Regardless of the bundling approach, a CI job can be developed as a part of the building process. It would take the assets, pack them and upload them to the server.

I'd like to suggest having only one pipeline. The associated operative costs of:

• QA-ing the new pipeline
• Selecting matching versions i.e. StreamableAssets_v3 and Renderer_v2
• Maintaining two or more pipelines, and their derived desktop implicancies

May be mitigated by assuming the cost of building the assets and deploying them on every build. The only downside is that during many versions, the assets may be exactly the same, not being able to cache them. For that purpose, we can later on create rules for the CDN like:

Redirect 301 https://cdn.decentraland.org/unity-renderer/<version>/StreamableAssets/hello.assetbundle
To https://cdn.decentraland.org/StreamableAssets/3b3a1258-95aa-11ed-a1eb-0242ac120002

Optimizing bandwidth and cache-hit at the cost of one hop/redirect

from adr.

My idea behind having a parallel job (within the same pipeline) is based on the assumption that we will reduce building time, since the assets can be packed in parallel.

In any case this decision is all yours, my knowledge of opeative costs of CI is super shallow and current build times are acceptable.

from adr.

We should evaluate the risks and costs of sticking with good ol' Asset Bundle or introduce Addressables.
Currently, we have a runtime for AssetBundles but nothing for Addressables.
Also if we want to start benefiting from it ASAP AssetBundles are our choice. It will not block us from Addressables in the future at the same time.

from adr.

My idea behind having a parallel job (within the same pipeline) is based on the assumption that we will reduce building time, since the assets can be packed in parallel.

In any case this decision is all yours, my knowledge of opeative costs of CI is super shallow and current build times are acceptable.

Oh ok, I didn't understood that correctly. As long as it is part of the same build pipeline we are ok, I was trying to prevent an independent pipeline that does not produce a single publishable artifact

from adr.

Oh ok, I didn't understood that correctly. As long as it is part of the same build pipeline we are ok, I was trying to prevent an independent pipeline that does not produce a single publishable artifact

Let me rephrase it, so it's more clear!

We should evaluate the risks and costs of sticking with good ol' Asset Bundle or introduce Addressables.
Currently, we have a runtime for AssetBundles but nothing for Addressables.
Also if we want to start benefiting from it ASAP AssetBundles are our choice. It will not block us from Addressables in the future at the same time.

@mikhail-dcl I have no experience with Addressables, we could do a quick spike to evaluate the costs. How would it work with ABs? prefabs with references to textures or scripts referencing audios will get them automatically once the bundle is loaded or do we need some integration stuff there? For what I've heard from Addressable they automagically solve this.

from adr.

@AjimenezDCL I have no further comments, I think this is OK to be converted into a PR

from adr.

As soon as we agree on addressables vs ABs Ill do it, thanks!

from adr.

Oh ok, I didn't understood that correctly. As long as it is part of the same build pipeline we are ok, I was trying to prevent an independent pipeline that does not produce a single publishable artifact

Let me rephrase it, so it's more clear!

We should evaluate the risks and costs of sticking with good ol' Asset Bundle or introduce Addressables.
Currently, we have a runtime for AssetBundles but nothing for Addressables.
Also if we want to start benefiting from it ASAP AssetBundles are our choice. It will not block us from Addressables in the future at the same time.

@mikhail-dcl I have no experience with Addressables, we could do a quick spike to evaluate the costs. How would it work with ABs? prefabs with references to textures or scripts referencing audios will get them automatically once the bundle is loaded or do we need some integration stuff there? For what I've heard from Addressable they automagically solve this.

I have never used Addressables on prod as well, so we need to perform a spike

from adr.

I would suggest going with Addressables, they have a bit of learning curve, that is true, but it also solves a lot of problems dealing with underlying ABs.
In the end, Addressables, are just higher abstractions API built on top of asset bundles, allowing for much more convenient fetching of assets. And it's much easier to maintain also the bundles in the project.

Addressable would also quickly solve the problem of moving assets away from Resources folder.
You can actually reference addressable in inspector without having direct reference to asset.

Our setup would be quite straightforward, so I don't think we would need to expand a lot on Addressables code for custom providers, which is the most time-consuming effort, because of the lack of documentation.

from adr.

I would go with Addressables, worst case scenario we fallback to ABs if we encounter issues

from adr.

We can have both systems running in Harmony.

What adressables were made to fix are the complex systems that you had to build around AssetBundles (what we have right now) to load certain assets, now you need less code and systems to achieve that.

So we will end up with:

• Using addressables to separate the build in cacheable chunks, this can be done using Adressable catalogs. Catalogs have versioning so we have to be careful about how we load them in case we have breaking changes in the assets and we decide to roll back one version.
• Using AssetBundles to optimize the scene assets to load them in WebGL. In theory we could migrate to adressables too, we will gain nothing from that but we will be using a more modern pipeline.

I completely agree with this change.

from adr.