Search Unity

The AssetBundle team is developing a new visual tool. We’re trying several approaches to improve the workflow around AssetBundles. Today we are releasing one of them as an open-source prototype. We hope that you will take a look and join the development.

The AssetBundle workflow has evolved a lot in Unity 5, but we are aware that there are still some issues. Since the release of Unity 5, we have spent a fair amount of time learning how you are actually using AssetBundles in production. We have also had a few public roundtables at events such as Unite 2015 Tokyo and discussed with you directly, to get a deeper understanding of what would make the wide variety of developers in Unity community happy.

Understanding the pain points of AssetBundle

After this research, we have found that following issues are very common among various studios:

  • AssetBundle are very often built and used for assets that are outside of scene structures and dependencies, such as avatars, card illustrations, virtual store items.
  • Many teams write their own in-house AssetBundle build pipeline for production for very similar purposes.
  • AssetBundle had been always tough to learn and use for beginners and small teams. It was also challenging for experts and large teams who need to spend time on creating their own pipeline to use it efficiently.
  • Many AssetBundles are pure graphics, such as textures and models. Many teams want to free their artists of AssetBundle configuration tasks so that they can focus on living DCC tools, creating actual assets.


Make AssetBundle workflow visual, more intuitive

An easy to learn and flexible visual tool for creating a build pipeline that can support some of the complexities of real productions, the Asset Bundle graph tool provides a workflow with the following features:

  • Create AssetBundles with no coding. Create nodes, connect them and simply press the build button to give you the AssetBundles you desire!
  • Easily understand what happens when you build: which files are targeted, where they go and how they are included in which asset bundle files.
  • Create pipeline in a rule-based model. So once you configure the pipeline and set up simple rules with name and path conventions, you can then completely forget about AssetBundle configurations. Share that rule with your team and just keep creating and adding assets as long as your team is following the conventions. When you press build, those new files are automatically targeted and you will get new AssetBundles accordingly.  

We have come to the point when we’re ready to share this with you. Like many other tools we released recently, we are releasing this tool in open-source, under the MIT license. The tool is still in prototype phase, so we would be delighted if you gave it a try and tell us what you think. You can also freely modify the tool to match your needs, or join in its development.


More Info:

Live Q&A with the Unity AssetBundle Team

Attending Unite 16 in Los Angeles? Don’t miss our session with Lead Engineer Stephen Palmer and others from the AssetBundle tech team. Bring your AssetBundle questions, stories, and feedback. Learn how others are using this feature and help drive its future direction.

Track: Breakout 2
Time: Thursday, 1:00PM PST

45 replies on “New AssetBundle Graph Tool Prototype”

This is an interesting tool that might have some use. But there needs to be a splitter component so we can have the same asset take multiple paths in the pipeline. For example, HD and SD could use the same textures but with different import settings. I thought the Filter could be used as a splitter, but the name of the output is actually the filter, so that doesn’t work.

Well it looks nice and usable, I don’t have a problem with it. I’m more of a use case where “why do I need asset bundles” and “how do I build asset bundles for DLC or streaming in-game” ?

Not quite sure where this fits.

Some of us use asset bundles for 2d games just for the png graphics and sounds to make them smaller in size and with the same quality. In this case I had to write my own pipeline code because I want to use the graphics in the Editor (see them) and when run in a device these graphics to be replaced with asset bundle graphics easily. I cannot work in the editor blindly. Please make something to enable us easily switch resolutions of our games with asset bundles. Eg use 4k resolution asset bundle and easily switch another bundle with HD resolution. Now I use my own code to do this.

This is a step in the right direction. Very flexible, but I think more complicated than needed for most developers.

We’ve developed something similar, but a lot simpler. We have a list of rules in inspector. Each rule has wildcard string which matches files in our Asset folder, platform it applies to, and target for the data (can be resources, bundle or excluded). Custom property drawer shows this on a single line. Super easy to use, and creates bundles we need to all platforms we need.

Without looking into details of your system – it seems it’s design to create bundles only. For us it’s a lot more useful to have system, where data can be marked as resources, excluded or bundles (per platform). We store all Assets in Assets/GameAssets, and during build step based on these rules we either:
– build a bundle from asset
– create tiny scriptable object inside Resources folder which references the asset (this makes it be included in Resources)
– do nothing (resources is excluded on a platform)

I’d suggest you extend your system to handle the ‘resources’ and ‘exclude’ assets as well. Perhaps it can already do it somehow. This gives us control over all data – and can decide per platform what goes to resources vs bundles, without having to move files to Resources folder.

Why do you want to use the Resources folder at all, though? It’s uncompressed, and always rebuilt every time you do a player build even when nothing in it has changed.

I agree with @Richard.
Additionally, the loading of data from the resources folder gets slower as you put more and more data into it. It sums up everything into one big binary file and to get something out of it, it has to open the file, search the right spot and extract the data from it. With assetbundles you have:
– smaller seperated files which could be more effectively loaded.
– don’t extend build times, as bundles are only included, but not build into the one resource file
– have better compression

Only problem (and that was already adressed before) is the platform dependency, which is not nice, but hopefully we get some help in future.

Resources have some advantages over bundles, which is why our pipeline supports them:
– on mobile, loading many assets from resources is faster than from bundles in streaming assets, and consumes less memory (we did test with about 1000 of bundles) – it made a 2 second difference to load into our game on ipad2 class hardware.
– Bundles can reference dependencies stored in Resources without data duplication. Bundles cannot easily reference assets in other bundles. See “4.5.1 Asset duplication” here:
This not only duplicates asset on disk, butt asset in memory if both bundles sharing same assets are loaded. Solution 3 they list is viable for this, but it gets hard to manage by asset creators.

I’d like to second this.

I don’t necessarily think that Martin meant “add to the resources folder” I think what he meant to say was “embed” the asset bundle into the binary. This way you can decide which asset bundles are included in the project during building, and which will be available for downloading at a later time. Wether that is done through the resource system, or the streaming assets system, or pre-cached in the www asset download cache, it’s nice to allow your project to assume that all assets are in asset bundles, and can be accessed in the same way.

After re-reading, I see he actually did mean using the resources folder. But I think the spirit of his message is still important. Being able to include asset bundles in a game should be stupid simple. A use case:
Choosing which level ships with your game, and which levels are DLC. It’s not uncommon for level order to change with a game.

You can drop your bundles into a StreamingAssets folder and load them from there, which is better than using the resources folder to hold them (well, anything, really).

This is actually how we handle the case of “I want to test something, but don’t want to check it in and test it from live bundles on a server!”. You build your bundles locally and copy them to the StreamingAssets folder, and on startup our loading code checks to see if the manifest is there before downloading one from a server. Makes testing much easier in a live environment.

This seems nice, but for me the biggest problem with Assetbundles right now is the lack of complete examples and up-to-date documentation.

As Jason Booth mentioned, supposedly the ‘new’ UnityWebRequest class will replace the WWW object but I have found zero Unity examples using this new class for assetbundles. Here is a link to documentation you initially stumble upon when figuring out how to do assset bundles, only showing WWW functionality and containing no mention of UnityWebRequest even existing:

The main tutorial on asset bundles also doesn’t mention UnityWebRequest at all:

Its a simple example of lacking information on this front, of which there are many more. (so please don’t reply with an answer, it’s just to indicate the issue)

Spending time on updating the documentation & providing complete examples seems much more efficient to me than building some tool that will (probably) take quite some time to be ready. I hope that the people Unity realize this! The people who’ve developed the Unity assetbundle system could probably make various complete, detailed examples AND up-to-date documentation in a week or two, while this will probably take months. And may not even fix all problems, resulting in small teams STILL having to write their own pipeline from scratch with bad documentation!

Hey Randy,
Ian’s guide is pretty thorough; but the sheer size of it illustrates the reason why there’s so much outrage here.

That said, every time I’ve tried to use web request in a real use case I’ve had issues with it. I have one open ticket about it still in support, but after 2 months and the last fix not working, I gave up on it and went back to WWW (note, this was not an asset bundle use case, but rather using it in a build environment). I need to send a new repro case in (yeah, I know, I’m not helping, but spending several hours to break out a minimal repro is more time than I have right now). The last time I tried using it for bundles, it would occasionally error out with 0.5 progress on a bundle and never complete (maybe the same issue that WWW had until recently when using too many at once? Same 0.5 progress issue)

Also, last I heard our rep said that when using WebRequest on android streaming sounds would not load correctly- is that still an issue? I’d like to give it another go before we ship our next game, but my time is precious and my confidence in this area is, well, shaken, not stirred.

Hey Jason, I’ll follow up with you off-thread on the UnityWebRequest issues.

On the complexity of working with asset bundles and the need for such copious documentation, Stephen & team are fully invested in making this a much more awesome system to work with!

The very first page of your guide starts out by saying it uses completely different terminology than the rest of Unity’s documentation. Please, take a look at the amount of frustration you’re hearing from developers on this page and anywhere else asset bundles are discussed, and ask yourself are you really helping things by using a completely different set of terminology than every other previous bit of poorly and incompletely written but heavily google indexed bit of documentation on asset bundles? PLEASE smack whoever thought it was a good idea to make this new asset bundle documentation completely incompatible with all previous asset bundle documentation, and tell them that they need to go through and do the search and replace themselves, on their document, to make it consistent with the terminology used everywhere else in Unity and everywhere else on the web that discusses asset bundles. They are not a special snowflake that needs to be magically different, they are one more step in Unity’s ten year history of failing to deliver adequate documentation for asset bundles. Hopefully they get it “right” this time, but developers are still going to be puzzling over that ten year history of google hits for a long time to come, and whoever is trying to clean up the mess needs to recognize those hits aren’t going away any time in the next five years. Seriously. Terminology matters. You don’t get to re-invent ten year’s worth of terminology that Unity has forced all of us to use just because you’re new to the team and to this particular bit of documentation writing.

Thanks Randy, I believe I’ve read this back when i was trying out assetbundles some time ago. I’d like to point out that the WWW dependency throughout the guide still seems very high for something that is to be replaced.

For example, in Streaming Assets it explains how the use of http://WWW.LoadFromCacheOrDownload is required for Android. (The next sub-chapter actually states that this function is flawed!) There is no mention on if it is possible to use the UnityWebRequest as a replacement, and/or how to do this. If it isn’t possible, that would mean that we would still be required to use WWW. Using both in a single pipeline feels a bit strange and I’d probably default back to WWW, not using the improved solution and sticking with legacy stuff!

Hi everyone,

As always we appreciate the spirited feedback. Hiroki has been working on this tool for some time now based on a lot of very specific feedback from developers in his primary region (Japan and other Asian countries). We figured it could be helpful to a broader user base as well. In the meantime Unity has been building a new team to own general development of asset bundles, which I’m leading now. Most of the specific concerns raised in these comments are known and understood pain points – I and my team are trying very hard to listen. Next week at Unite in Los Angeles, I’ll be talking a little bit about how this new team is approaching the known issues around asset bundles, our driving principals for development, and a short term roadmap. The rest of the time will be for Q&A. I hope you can join us if you can. Of course we’ll be publishing materials from that session afterwards for those that can’t attend.


That is already possible. Previously you used BuildStreamedSceneAssetBundle, but it should also work with the new system. I’m pretty sure I used it one of my 5.x projects already.

So, my main issue with this is that this tool shouldn’t be needed in the first place. We don’t need to do this for a normal build process, so we really shouldn’t have to do it with asset bundles either.

There is really little difference between having these files stored internally or externally- at the end of the day, they are a glob of binary data that needs to be loaded, which may have dependencies on other globs of binary data which need to be loaded. Yes, there’s a fair bit of wrapping around that loading process, but it shouldn’t leak out into the users workflow the way it does.

The current system assumes we need an extreme amount of flexibility for this- manual control over creating them, breaking them up, manual control over loading their dependencies, etc. But in most cases, the only thing we really want control over is “Where do I download this file from?” and “Which version of this asset do I want”. I can’t think of a case where we want to, say, not load the dependencies a bundle has. Or a case where we want to ignore the hash on the file and use the local one instead of fetching the latest one when it’s out of date. The only real reason for breaking up bundles is that the loading is not atomic (will download the entire thing even if only one file is needed) and that WWW blows out the highwater mark on the mono heap.

We are managing most of this by hand for little gain and lots of lost productivity. We’ve almost completely automated the process for our games, but it tooks months of work to do so – work which should have been spent on the game instead of serialization.

Combine that with excessive race condition bugs over the 5.0 cycle, undocumented limitations in WWW and iOS file loading, the un-usability of WebRequest as a WWW replacement due to bugs, and the whole thing has been the most frustrating part of using Unity, IMO.

Can’t disagree with you more.

Depending on your target platform, how you construct your asset bundles can be HUGELY important. For mobile products, not only do you want to keep your initial download under the OTA limit, you want to minimize the amount of download pain your players incur at any given time, which means delivering only the assets that player really needs. That’s without even getting into the problem of possibly delivering customized asset bundles that target specific devices (e.g. in the past, it was insane to deliver retina-quality assets to older, non-retina devices, since not only could they not display them, it actually added overhead to those slower platforms to rebake them after downloading).

It’s a very nuanced problem, with multiple interacting axes of complexity.

@Tim Keating
The current asset bundle system is actively working against (with a vengeance) the goals you mention.

My last game shipped on Android, iOS, and webGL, supporting very low end devices. The app itself is 39 megs, with over a gig of data in over 5000 asset bundles with three variant levels. We downloaded alternate versions of everything for different device performance levels. We fixed bugs in Unity’s source code to prevent various race conditions and issues in the asset bundle system from crashing our users. I’m VERY familiar with the system at this point.

Untiy’s default behavior with the asset bundle system basically comes down to:
1. Duplicate as much data in memory as possible
2. Enforce maximum download size for the user
3. Be as manually and developer unfriendly as possible if you want to prevent #1 or #2

Lets take an example. I have two prefabs, I want to load them from code, and they happen to rely on the same texture. If I load this from the regular build system- it just works. It finds the texture fine, and only loads one copy of the texture in memory.

With asset bundles, I assign them each to a bundle so I can load them, then the texture will be duplicated into both (issue 1&2). And, loading a large bundle with WWW will allocate in the mono-heap, so I need to load more, smaller bundles. So now (issue #3) I must manually go through the things which are shared by multiple bundles and put them into their own bundles.

RULE: Put everything in my project which is shared into it’s own asset bundle.

Now I want to deliver a variation on that texture to the user, depending on what type of device they have. Lets keep it simple and say we only have a high and low detail version. Per Unity’s recommendations, you’re supposed to duplicate your texture and assign it to two different bundle variants. Now I need to keep both these files in sync (essentially 2x my source files for no reason), and when assigning a texture both will be shown to the user as if they are different textures, but if my user choses the wrong one (which look and are named exactly the same in the texture selection window), then the asset bundle system will throw an error because they are using mismatched variants in the source art.

Ok, so now I’ve marked every asset in my game, and everything they rely on, into their own bundles and made two copies of every texture in the game so I can have a high and low detail version. Now that every asset is it’s own bundle, I’ve solved issue #1 & #2 at the expense of making the workflow extremely tedious and error prone. But hey, I can load just the variant my device needs, and I’ll only download exactly what I need and only have exactly one copy of each asset in memory! Yay!


Turns out until mid-5.3, there was an undocumented limitation that you can’t have more than about 200 asset bundles open at the same time. So now we have to manually combine some of those bundles so that no moment in our game every has more than 200 asset bundles loaded at once (and oh yeah, audio bundles count twice!). But which ones do we need to combine? If we get it wrong, we download more data than the user needs. So we combine a bunch of the smaller stuff together and aren’t quite perfect on #1.

RULE: Put everything in my project which is shared into it’s own asset bundle; but don’t every have more than ~200 bundles loaded at the same time, so monitor that and merge bundles back together again if you approach that limit. Also, dupe all your assets once for each variant you need to deliver.

Try again: Some percent of users CRASH

Oh, you’re downloading more than one asset bundle at the same time; fine, but just don’t try to access more than one per frame cause we have race conditions (got this one fixed)

Try again: Some percent of users HANG

Well, WWW has an undocumented limitation on how many requests you can create at a time, so you’ll need to delay your dependency downloads to make sure you don’t go over that maximum. If you do, the download never finishes and progress stays at 0.5

Add throttling code to our loader.. (Fixed about a month ago in a 5.3 patch)

Try again: Some percentage of users crash

Oh, yeah, you’ll have to use the non-async loads because the async ones can crash sometimes.

RULE: Put everything in my project which is shared into it’s own asset bundle; but don’t every have more than ~200 bundles loaded at the same time, so monitor that and merge bundles back together again if you approach that limit. Make sure you don’t have more than 25 WWW requests at once, make sure you don’t use the async loader (still busted!), make sure none of your bundles are large enough to cause memory issues since they end up in the mono heap, Have multiple copies of every asset in your game around so you can compress them differently for different variants, but don’t accidentally select the variant version of the texture when working even though it will look exactly like the correct one in the UI as that will cause issues.

Anyway, I could likely expand this several fold. The system is fundamentally flawed in many ways (even without the bugs) and should be replaced with something that “just works”. I’ve actually automated away most of our issues for our current project with some help from Unity’s CTO, who was very generous with his time, but it was months of work. Many of the bugs we encountered have been fixed, but even with them fixed the system asks way to much of the user for what it does.

My current process works like this:
– Only place things your going to load directly from code into asset bundles
– At build time, build up a list of all assets these bundles rely on
– Put every texture/sound/mesh into it’s own bundle unless it’s tiny. Auto-name them based on the path.
– Take all the remaining tiny objects which are used in more than one asset and cluster them into common asset bundles based on ‘proximity’ to the assets that use them.
– Build bundles for each variant level. For each variant, scan through all the textures and sounds and adjust their import settings for the variant level and reimport them (using the cache server). Then use perforce to revert the changes and setup the next variant.

Hi Jason. Great description of your struggles, you’re giving out a lot of useful information. I wonder if you ever documented it in a blog or something similar.


Not in a blog- I talked quite a bit about it in my Unity 2015 talk:

At some point I’d like to give out the code for how our new system builds asset bundles (I was thinking of this being our code givaway for our unity 2016 talk, but it wasn’t accepted). We’ve been running it on our Walking Dead game for a few months now and it’s pretty stable and removes a ton of the issues we had in STT. It’s not an indie solution- you have to setup build machines with revision control integration, etc, and would likely need to customize it a bit for your environment, but once you do you can avoid most of the marking work and just let it do it’s thing.

Who would use this tool?

A programmer is already capable of creating this in code, which usually has preference since he knows how to code and there are existing workflows and tools to do so.

The frustrating workflow, some unanswered questions, and the bug reports/forum threads about AssetBundles being annoying and a bit unfriendly means that we’ve never really used them. Overall, given Unity is a cross-platform engine, the current state of dynamic and per-platform assets is fairly average. Improved workflows to help scene and object configuration per-platform would be great, along with things like support for standard vs high-density screens, amongst others.

It’s great that frustrating parts of the development process like this are receiving some attention. Hopefully the features and documentation for them continue to improve. Actually, I hope the docs in general continue to improve. There are plenty of features and script reference entries that are too bare-bones to be useful without finding forum threads or developer blogs to actually learn how to use them. The editor scripting docs in particular aren’t that useful by themselves.

Keep working hard please Unity!

Yeah, that’s great and all but seriously, there are problems with Asset Bundles that are way more important than this and that are unsolved when it’s not just completely ignored.

In the last year, I filed multiple bug reports about bundle, some are not fixed yet, some were half fixed. Regressions in the asset bundle system prevented us from upgrading Unity regularly.

Less that 2 weeks ago, I filed a bug report when 5.4.2f1 got out about a regression in 5.4.1p3 that prevent some bundles to load (internal Unity failure) and I got a completely unacceptable answer from QA that was “use the 5.5 beta”.
As it is, this answer is just completely missing the point of what developing a game is but it’s even more idiotic when the asset bundle change in 5.4.1p3 that probably caused all this is not in the 5.5 yet.
Since I replied to that, I’ve not heard from QA again, the bug is still not sent to resolution and we’re completely stuck with 5.4.1p2.

So yeah, sorry but this blog post just infuriates me.

Great but there are important issues with asset bundles currently to be honest (bugs reported, no replies)

5.4.x spams the console with warnings about shaders in old asset bundles so you could fix that or explain it better:

Secondly your documentation does not explain the compatibility between platforms fully so I have no idea if an asset built for windows 64 is compatible with mac 32 for instance!

I must agree. Fix the broken stuff. I’m not sure how this new tool will help me automate producing 800+ assetbundles for my current project. I already have to go and re-build them now to try and work around the bugs introduced in 5.4 over 5.3. That together with the poor documentation doesn’t help things. Please fix the less sexy things first. As anyone who deals with assetbundles already have a stable of tools coded up. But what is annoying us is Unity constantly adding regressions and (still) poor documentation.

Nice post. Still I think there are some major problems in the workflow with ABs:

1. Platform dependency.
If you want to build for several platforms, you have to switch each time to that platform to build the assetbundles. If you have a a large project with many texture assets, it takes sometimes hours to switch the platform. So the solution (or better workaround) is to check out the projects so many times as platforms and let them stay on that platform.

2. Debugging
Once build, it is hard to check what is actually in your assetbundle from your code. So what you need to do is load all assets from the bundle and check what type they have. The manifest file which is generated during the build is helping a bit, but I would expect something like that in the assetbundle.

3. Versioning
Versioning seems to be a bit weird. We don’t have to check which version the AB is, but we have to manually maintain an external file with version information (bundle verion and crc value) to know if the application needs to download something. While the idea of versioning is nice, why is something like that not included into the AB and the engine checks itself if it needs to download the data.

That aside, I totally agree that the AB system and workflow has improved a lot and I also agree, that there are still too many people not knowing how to use them or what benefits they have.

Thx for the note. I’ll take a look into it. Currently we have a seperate project for the assetbundle datas, but with each platform supported, we need to check out the project again. That’s a bit tiresome at some point and will increase waiting times to build all platform assetbundles.

Thought the cache server is dead? Think Joachim told us more than once that it won’t get any love in future anymore, or am I wrong?

Comments are closed.