Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

1.1.4 Cannot Build Player Content

Discussion in 'Addressables' started by mlaibow, Jun 25, 2019.

  1. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    I have been using Addressables through many versions of the Addressables package as well as Unity.
    It worked great up to and including 0.5.3.
    Any attempt to update the Addressables package beyond 0.5.3 resulted in the same problem:
    When I run Build Player Content, it runs until it says Write Serialized Files, at which point it freezes.
    The task manager shows that Unity is using 48GB of ram and 5% of the processor when it is frozen, so it seems to be doing something.
    I cannot see anywhere on the HDD that it is actually writing the files, it appears that it created them in RAM and then is not able to write them to disk.

    I know that there were breaking changes for the update to 0.5.4 about the locations for build and load paths, but I have followed that migration, and I have even used the various settings files and scripts from the Addressables sample which is built for 1.1.3.

    I still think it has something to do with the target paths, but it all looks okay to me.
    There is no info in the logs, it just sits there saying that it is Write Serialized Files with nothing actually happening anywhere.

    Any thoughts about what could cause this? What else, besides the load and build path syntax has changed since 0.5.3?

    Thanks,
    -mat
     
  2. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    I should add that I am using Unity 2019.1.8f1, however, I have been unable to build the packed content with the same freeze point in multiple versions of Unity, whenever I use a version of Addressables beyond version 0.5.3.

    With the code changes, it is also getting a bit difficult to roll back to 0.5.3 and I would really like to get 1.1.4 working. The game runs fine in the editor, it is just the Write Serialized Files part of the Build Player Content that does not complete.

    Also the Analyze feature of the Addressables package runs perfectly fine as well. Same with all of the steps leading up to the write, so the shaders compile and the asset dependencies are all checked.
     
  3. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    954
    Please file a bug against Unity with a repro project. Also, I do not expect things to work if you upgrade directly from 0.5.x to 1.1.x. We have some data upgrade/conversion logic in the package, but not for that large of a jump. You might need to upgrade from 0.5.x to 0.6.x and so on. Either way, with a repro project we can look into it on our end.
     
  4. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    I just did a complete rebuild of the addressables package. So I removed it along with the scriptable build pipeline package, deleted the Library folder and all other project instances, reimported, reinstalled the Addressables package, reset up my asset groups, and now I think I know what the problem is...

    When I mark a large asset file as Addressable, it will not build. It will lock up for more than an hour and eventually fail with an I/O exception, Stream Too Long.
    It has nothing to do with how many files are in an asset group, just the presence of a file over a certain size.
    In my case, this is just a 30MB FBX file, which is not unheard of since an FBX file is a container that can have many objects in it. I have a handful of large FBX files, so I am about to dial in on exactly what that size limit is.

    This issue did not exist in 0.5.3, before the scriptable build pipeline dependency, as I have had these same files as addressable assets at that point and they packed just fine. In fact, I also have a 70MB FBX that works fine in 0.5.3.

    A post from yesterday in the Addressables Are Here thread shows someone else with the same problem.

    If I mark 4x ~8MB FBX files as Addressable, the build works. So the issue is with single files larger than a size somewhere between 8MB and 30MB.

    To reproduce this bug, simply import a large FBX file with a lot of meshes, mark it as addressable and Build Player Content.
    I can create a special project to do this and post a bug report, but it will take me a few days, and my complete existing project seems to be too big for the crash reporter to post without hanging after more than an hour of attempted uploading.
    I will do it, but I think you should have enough to go on to at least look into it.

    In the meantime, would it help if I just post a large FBX file?
    -mat
     
  5. Kolyasisan

    Kolyasisan

    Joined:
    Feb 2, 2015
    Posts:
    262
    Yes, it was me with that issue in the main thread. In my case though it happens when I have a bundle with a lot of small assets in them, like materials and basic scriptable objects/scriptable objects that reference assets from other bundles. It is most definitely a problem.
     
  6. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    Yeah, I just tried a large image file and it worked fine, so this all makes it seem like it is related to the quantity of individual assets that it is trying to pack (directly or as dependencies) and it is treating an FBX file as a collection of individual assets.

    Another counter, index, or file pointer with not enough bits perhaps?
     
  7. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    I created a very clear project that reproduces this problem and filed it with the Unity bug tracker.
    It is a completely empty project with just the Addressables package installed with its dependencies.
    I added one somewhat large FBX file to the assets.
    If that file is marked as addressable, the build player content fails after a long time with the stream too long exception. If it is not marked as addressable, it works as expected.

    This exact FBX file packed fine up until Addressables 0.5.3.
     
  8. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    I can confirm that this bug still exists in 1.1.5 starting with a completely empty default project. Building the player content hangs and fails with the addition of just one large FBX collection of meshes.

    And it has been almost 3 weeks since i submitted the bug report. There has been no action on it. I would have thought that the bug posts would have been at least reviewed before a package comes out of preview.
     
  9. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    954
    What is the ticket number? The bug process can take time, especially over the summer months, but if you tell me the number, I can make sure we're looking closely at it.
    Thanks
     
  10. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    The bug ticket number is 1166277.
     
  11. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    249
    Hey @mlaibow
    Started digging into this today, and the problem in this case isn't limited to Addressables / Scriptable Build Pipeline as this FBX asset also causes problems with the existing Build Pipeline too. There is an issue with the hashing methods of SBP causing an error that we will fix, but build time for this asset is mainly due to a scale issue with this FBX & expected Asset Bundle behavior.

    So to get a bit into the details:
    When you import an asset into Unity it generates the equivalent set of Unity specific objects that make up the asset, with one of those objects being the Main Asset (basically the root object) which appears in the Project Window, then the rest of the objects are Sub Assets (objects that are referenced either directly or indirectly by the root) with some of them being classified as Asset Representations. (objects that you see in the Project Window when you click the expand arrow). Now asset representations is where the problem occurs.

    Using a similar pattern: Sprite Atlases. Typically you will have a texture imported with several sprites as sub assets marked as asset representations, and at runtime you usually want to get to the sprites, but the texture is the main asset. This is where the asset representations come in. At build time, loading path entries are generated for each sprite so you can quickly get the sprites from the asset itself. And this works as there usually isn't many asset representations in this case.

    In the FBX provided, Unity is generating 13533 representations for this asset. (1 main game object asset, 6764 sub game objects, 4 materials, 6764 mesh objects). So this means it's generating 13533 duplicated loading path entries all being added and sorted in the bundle. Which in this case causes the long build times. Now we can easily turn off this behavior and then the bundle only takes seconds to build as then it generates only a single path entry for the asset. The downside is this breaks many use cases for 2D projects. So this is where SBP flexibility comes in; we can very easily modify this behavior, the hard part is going to be figuring out the correct UI/UX for users. In the short term I can whip up a quick code snippet and post it here for removing or modifying this behavior in your specific project if you would find that useful for now until a long term UI/UX fix is implemented.
     
    Last edited: Jul 23, 2019
    unity_bill and hanniiel like this.
  12. mlaibow

    mlaibow

    Joined:
    Feb 5, 2014
    Posts:
    30
    Wow, Thanks!
    It would definitely be useful to have a code snippet that can create a single path entry to a large container asset in the scriptable build pipeline. I assume that I can create a copy of the current build script, add this code snippet to it, but selectively apply that build script to the asset groups that have these large container files in it?

    In case it helps, my workaround for this problem has been to first re-export the meshes from max in multiple smaller FBX files (duh), then i have not been using addressables, just the standard asset bundles. And I only put the prefabs that use the meshes from the FBX files into those asset bundles so they pull in the dependencies. The bundles pack quickly and the build times are acceptable, and it does not hang.
    But if I understand your post correctly, it is the separation of the FBX into smaller files that fixes the problem because the issue still exists in the standard build pipeline.

    While I don't plan on going back to the giant single FBX files since I have split them all up, I still would want to get back to using addressables and the ability to create a single entry path for a collection would speed up packing and building and in my use case I never needed the individual paths to the mesh files anyway.

    Thanks again!
    -mat