Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Unite 2023 Registrations are now LIVE! We are thrilled to announce that Unite 2023 Registration is now live and open for all!
    Dismiss Notice
New Forum User Notice Unite 2023 Registrations are now LIVE!

[bug] BuildUsageTagSet - GetHash128 depends on the order of UnionWith

Discussion in 'Addressables' started by nik_d, Jan 31, 2020.

  1. nik_d

    nik_d

    Joined:
    Apr 27, 2018
    Posts:
    66
    BuildUsageTagSet - GetHash128 depends on the order of UnionWith in Unity 2018.4.15f1.

    Proof: attached project BugBuildUsageTagSet.zip
    Execute menu item "[Test BuildUsageTagSet UnionWith]/By Items" or "By Blocks" and see "BuildUsageTagSet unions are different!" assert-error message in the console.

    I was not able to build a minimal reproduction test with assets, but I have digged to bug via production bundles build logs.

    It brings us more than needed bundle rebuilds, more different hashes and much more re-downloads to end-users after releases (sometimes >1gb instead of ~100mb).

    It looks like already fixed in 2019.3.0f5 (and even BuildUsageTagSet.SerializeToJson is better sorted there). But we cannot switch to 2019 soon.

    Questions:
    1) *Is the fix going to be back-ported to Unity 2018.4?*
    2) Is workaround in GenerateBundleMaps.cs to deserialize/sort/serialize fix the problem? (or corresponding BuildReferenceMap is sorted wrongly too and the final bundle hash will be modified in any way..)

    Thanks in advance,
     

    Attached Files:

    nik_d, Jan 31, 2020
    #1

  2. davidla_unity

    davidla_unity

    Unity Technologies

    Joined:
    Nov 17, 2016
    Posts:
    736
    Hey @nik_d I'm unaware of the changes added to 2019 so I'll have to find out when that happened and see if a backport is planned. Looking at what's available I'm not see a good workaround potential at the moment. I'll see if I can get a backport going.
     
    davidla_unity, Feb 5, 2020
    #2
    nik_d likes this.

  3. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    We've looked into it, and backporting this to 18.4 is not straightforward (not low risk) and would introduce churn for a lot of users already built bundles. So we are not going to be able to do that.
    But, your workaround in GenerateBundleMaps, while not very clean, does work. So our recommendation is to stick with that workaround until you can update to 2019.
     
    unity_bill, Mar 6, 2020
    #3
    nik_d likes this.

  4. nik_d

    nik_d

    Joined:
    Apr 27, 2018
    Posts:
    66
    1. Bill, I'm really appreciate your reply and am trying to force our team switching to 2019 asap (we just wait LTS mark although imho it means nothing for us).

    2. But let's dance further.)

    In GenerateBundleMaps.AddUsageSetForFiles we propagate BuildUsageTagSet from the asset to every dependant file. It sounds reasonable but *it makes even our textures to be rebuilt when absolutely independant shader have been changed (e.g. default with unity update)*.

    I have tried to replace `foreach (var file in files)` with just `var file = files[0]` (main asset file), but have got a visual problems in several scenes.
    Didn't tried to investigate, but still think it looks like a workaround for the something complex and *brings us unnecessary rebuilds for assets (just about every texture depends on a lot of absolutely independent of it shader variants)*.

    What was the initial purpose for it?

    UPD: wasn't correct:
    *texture is rebuilt with absolutely independent scene changes (e.g. adding to the scene new material not dependent on this texture).
     
    Last edited: Mar 7, 2020
    nik_d, Mar 7, 2020
    #4