Scriptable Build Pipeline with Asset Bundles issues

I've run into some issues with the Scriptable Build Pipeline (SBP) and am not sure if this is intended behavior, or will be fixed in the future.

I wanted to use the SBP with our current Asset Bundle work-flow. So after reading through the documentation, I switched over to using the CompatibilityAssetBundleManifest class. However, it seems it's assumed that this file will live inside your unity project somewhere, as it is a ScriptableObject. In our project though, it lives on a server or on disk somewhere not in the Unity build. The old AssetBundleManifest class was always contained in an AssetBundle, so loading it was relatively easy. The new one is not however. I can get around this just by creating an instance of CompatibilityAssetBundleManifest and adding an extension method to parse the file manually. It's doable, but seems like there should be built in functionality for reading the file from a Stream. Also, there seems to be a bug when the CompatibilityAssetBundleManifest gets serialized to file in which it does not insert a new line for asset bundles that have dependencies. So the next info entry item ends up on the same line as the last entries dependencies. I can parse around this, but seems like it should be fixed on your side.

The next issue I ran into is folders marked as an Asset Bundle are not built. I had to explicitly set each asset in the folder to be in the asset bundle. This differs from the old system, where I could just mark an entire folder as a bundle. This may be an intentional change, if so it was not clear to me. I know the Asset loading path behavior changed and now requires a full path to avoid naming collisions. If this is an intentional change, I believe that should be noted in the SBP documentation explicitly as lot's of people may be using folders as Asset Bundles.

The last issue I ran into was that asset names now seem to be case sensitive. Where as using the old system, all asset names seem to be converted to lower case on the build of the asset bundle. Not sure if this is intended behavior or not either.

 

Thanks for the reply. I was using 2018.3.7. So after updating to 2018.3.9, I was able to confirm the folders marked as asset bundles were built properly.

I guess I just missed the part about case sensitivity. I do it see it now under DisableLoadAssetByFileName.

I would like to suggest one feature for building asset bundles in the future. It would be nice to know which asset bundles were actually rebuilt. Currently, it's just kind of a black box. I tell Unity to rebuild the asset bundles, it determines which ones need to be built, and builds those. I've never been able to find a built in way to determine which bundles actually got rebuilt. I can get around it by storing the old manifest and comparing it to the new manifest now. Just always thought it'd be kind of nice to have this built in functionality though.

 

All I need to know is just what was built from the last time bundles were built. I just want to know so I know what changed and what needs to be copied or uploaded. I'm sure other users may have other needs for this as well.

We're currently not using the cache server integration, but I had planned on looking into it at some point in the near future.

I'm not really familiar with the PrgoressLoggingTracker. So, that's something I'll have to look into.

 

Hi, got some problems with upgrade to SBP. We are using Dry Run build option to determinate if bundle is outdated or not. It took around 10secs to check all bundles in project. Now seems that correct way is to rebuild outdated, but it takes far more time. Any hints how to check bundle state and not to rebuild it ?

 

Edit: Made some research and seems that good option is to call build tasks only till post packing event, then grab Hash128 from this point. But...seems like there is difference in Post Packing hash and hash generated from cooked bundle... In case of ~10k files packed in bundles still there is not the best option to build from scratch each time, looks like Library/BuildCache also growing fast in size...

 

You can achieve a case-insensitive Scriptable Build Pipeline by utilizing AssetBundleBuild.addressableNames.
However, keep in mind that this method loads assets in lowercase, which may lead to case-sensitivity issues compared to using BuildPipeline.
Here's the code to apply:

Code (CSharp):

1. var assetBundleBuilds = ContentBuildInterface.GenerateAssetBundleBuilds();
2. for (var i = 0; i < assetBundleBuilds.Length; ++i)
3. {
4.     assetBundleBuilds[i].addressableNames = assetBundleBuilds[i].assetNames
5.         .Select(e => e.ToLower()).ToArray();
6. }

By using this code, you can build and load assets with their paths converted to lowercase.
While you could call ToLower() each time you load, doing so would generate a significant amount of garbage and negatively impact performance.
Therefore, after minimizing cases of accidental incorrect calls by converting to lowercase during the build of tables and similar components, we adopted a strategy of checking if the load was successful (null check) when loading and, in case of failure, loading in lowercase as a backup.

Thank you so much, Ryanc_unity.