Search Unity

Caching Query and loading large file terrain

Discussion in 'Asset Bundles' started by KyleHatch85, Dec 7, 2017.

  1. KyleHatch85

    KyleHatch85

    Joined:
    Dec 13, 2011
    Posts:
    99
    Hi. We've been using asset bundles for some time with little fuss, but as newer features are requested we have to update the version of Unity we are using. This calls for the Asset Bundle loading system to be overhauled.

    As part of R&D i created the attached file, which is a script for loading the asset bundles in with the different techniques available.

    We noticed a significant increase in loading time compared to loading from Resources. A few seconds for resources, 66 seconds with load from File.

    This would be acceptable is the caching system was beneficent. Using the Unity Web Request system i added in a part to cache files, this has made repeat loading slower.

    So my query is two fold. Should loading large asset bundles be that much slower with Load from File for initial loading? Is there a more efficient way to cache than the one implemented in the shared file?

    Info: Model loaded was approx 3.6 million polys, made up of over a 1000 different objects, this is one large moving model used for our environment.

    Thanks
     

    Attached Files:

  2. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    332
    What options did you pass into the Build API for the bundles you are testing?
     
  3. KyleHatch85

    KyleHatch85

    Joined:
    Dec 13, 2011
    Posts:
    99
    Originally I built all of the AssetBundles via script. Tried using the default None options to build, then tried ChunkCompression and Uncompressed, just to cover our bases. Loading from Uncompressed seemed faster, and file size isn't an issue for us as these bundles are always loaded from the local machine.

    Recently i've been using the Browser which i believe defaults to lzma. It's more organised and doesn't seem to effect the loading speed of the bundle all that much.
     
  4. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    332
    So to start off, we have been made aware of some slow loading code when using the Caching System vs AssetBundles not using the Caching system that we are currently debugging. I don't have an eta for an update on this just yet.

    Outside of that however, there are a few things I can talk about in your test and comparing it to Resources. To start off, all serialized data has the same general order of operations required when loading an object: The Serialized File that contains the Object you want to load needs to be mounted first, then the Object can be deserialized into memory. Mounting the serialized file also consists of decompressing part or the whole serialized file depending on compression level. (Uncompressed, LZ4, LZMA: From best to worst case loading performance).

    Now these two steps are very important to keep in mind when comparing Resources vs Asset Bundles because Resources are mounted automatically at Game Launch, while Asset Bundles are mounted when you call LoadFromFile, LoadFromMemoryStream, etc. On the other hand, Object deserialization occurs similarly in both cases when you call Resources.Load / assetBundle.LoadAsset. In your code example, your timings include both mounting and deserialization for an Object in an AssetBundle, so when comparing it to Resource.Load (which is just deserialization) it's definitely going to appear a lot slower. For some extra comparison, try timing the startup of your project with your assets in Resources vs after you moved them to Bundles.

    As for bundles in the Caching system, the biggest benefit is that it will recompress LZMA bundles to LZ4 or Uncompressed during the download process so that you can download very efficiently packed LZMA bundles, but not have to deal with the drawbacks of mounting LZMA bundles. (https://docs.unity3d.com/ScriptReference/Caching-compressionEnabled.html). However as mentioned earlier, there is some extra slowness (?) in the Caching system that we are looking into right now.