Search Unity

Resolved What can and cannot break

Discussion in 'SRP Dev Blitz Day 2022 - Q&A' started by jbooth, Sep 28, 2022.

  1. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    Unity QA will often close bugs with reasons like "Someone might be relying on this behavior, so we cannot fix it" - yet the SRPs break things every release. What is the actual policy around breaking changes, because it seems to be very inconsistently applied across Unity.
     
    jbooth, Sep 28, 2022
    #1
    LaireonGames, glenneroo, Elringus and 2 others like this.

  2. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    765
    I'll do my best to explain how we try to make those decisions (especially in HDRP) but this is not a straightforward process and AFAIK, there's no actual policy consistently applied, it's more of a case by case scenario.

    Basically, what is being done on our side is we try to minimize the collective user pain by trying to balance on one side "How many users is probably already using this in a production" and "how many users will be impacted negatively in the future". Sadly, it just cannot be positive for everyone, we just try to piss off the least amount of people.

    For features that have been there for a while (think LTS and later), that's a no brainer, we absolutely try not to break rendering of it, like if we add additionnal feature, it will be be behind a checkbox off by default.. etc.

    If the "thing reported" was really broken (even though some users did not see it at first), we either just change it to make it correct if the change is subtle enough. If the result is really visible and different, we usually provide an upgrapde path (meaning the code will be upgraded to make it as close as it was before the change). We do our best, but this can sometime be forgotten because of the halo effects of some changes, it's hard to think of ALL the dependencies.

    For feature in development:
    • in alpha version (think water surfaces), they are available mostly to get feedbacks from users, and they absolutely shouldn't be used in a production whatsoever. So we don't really hesitate to break them. We really focus on trying to give the best experience to users that will use it when it's officially out.
    • In beta, we technically shouldn't but we allow us to break some of the things if what is there before was just already bad, so eventhough it's more stable in beta, it can still change depending on the context.
    So to sum up, as a feature gets adopted by more users, it's less likely that we'll break it (even if it's bad but is been there for ages).

    Do you have any examples of what might have broke recently so that I can provide reasoning if I can?
     
    chap-unity, Sep 29, 2022
    #2

  3. LaireonGames

    LaireonGames

    Joined:
    Nov 16, 2013
    Posts:
    705
    Its a minor one but this has always annoyed me:

    Screenshot_7.png

    Its been deprecated for so many years but because its higher in alphabetical order it always comes up first for auto completing.

    I feel like there are a few examples like this where the code that is deprecated has been around for Many years and really isn't complex to fix/replace. This is the one comes to mind first but if I think of others I will post here
     
    LaireonGames, Sep 29, 2022
    #3

  4. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    Some examples:

    If Unity is set to gamma rendering, saving a texture to disk as an EXR texture which is linear will have gamma correction applied. This basically destroys the data, because you don't get the same data back which you saved, making it useless for any kind of HDLut. This bug was closed because "People might be relying on this behavior", which I can't imagine how because it literally destroys your data. The workaround I use now is to use a ScriptableAssetImporter to write the bytes to disk and back, but that doesn't allow interop with external programs.

    The Terrain Details API takes an int[,], but internally converts the data to a byte[,] (though the docs says it uses an R8 texture internally). I suspect this is because JavaScript or Boo didn't have a byte type back when it was written. But interfacing with this from the GPU means rendering to an R32_SInt texture which is not available on all platforms (OSX, for instance) and wastes 4x the memory, or on platforms which do not support it, I have to rendering to an R8 texture and then run a job to expand that into a int[,] which allocates 54 megs of mono heap in my example scene, then assign it. This all seems pretty silly if indeed the documentation is correct and it's all going to end up an R8 texture anyway.

    Meanwhile, I've been maintaining an abstraction for shaders for the last several years that breaks approximately every 3 months - now I know the answer there is "Do everything in the shader graph", but you simply cannot write the kind of shaders I write in a shader graph.

    So what we end up with in these cases is some kind of sacrosanct API that is either unusable or massively inefficient, and is unlikely to ever be fixed, or an API that breaks really often with no documentation. Neither of these really scale well to real world production cases.
     
    jbooth, Sep 29, 2022
    #4

  5. LaireonGames

    LaireonGames

    Joined:
    Nov 16, 2013
    Posts:
    705
    Another example: Screenshot_1.png

    Building a little on what other Jason is saying (I'm also Jason for context) it worries me when I see such simple changes like this around for so long that Unity seems afraid to change yet there are so many bigger and much more important changes that also need to happen.

    The gamma issue is one I find particularly annoying as well since I work with texture arrays and its a confusing mess when trying to deal with the raw data it stores vs generating preview textures for use in editor windows etc. I am more than happy for my code to break again if it means that we have a clear and consistent behaviour for gamma because it means when I find a bug in a few years time I don't need to remember why I did things in a weird way to work around Unity's inconsistencies.
     
    LaireonGames, Oct 3, 2022
    #5