Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Enter the 2020.2 Beta Sweepstakes for a chance to win an Oculus Quest 2.
    Dismiss Notice

Reversed z-buffer and UNITY_SAMPLE_DEPTH

Discussion in '5.5 Beta' started by Kronnect, Nov 15, 2016.

  1. Kronnect

    Kronnect

    Joined:
    Nov 16, 2014
    Posts:
    2,524
    Hi there,
    Regarding the new reversed z-buffer introduced in Unity 5.5 is there any chance UNITY_SAMPLE_DEPTH macro will be modified so it takes into account this?
    I know Linear01Depth and LinearEyeDepth function will automatically handle this for us, but what about the above macro?
    Thanks.
     
  2. fguinier

    fguinier

    Unity Technologies

    Joined:
    Sep 14, 2015
    Posts:
    114
    Hi Thrawn75,

    Imho SAMPLE_DEPTH_TEXTURE not reverting the Z is a good thing :
    * The idea behind that macro and the UNITY_SAMPLE_* macros is to abstract the sampler declarations and texture fetch thus i would personally not expect them to alter the result (for clarity sake).
    * as you say, if one want to work on linear depth or eye depth Linear01Depth and LinearEyeDepth do the trick (at not additional, cost by the way).
    * if one want to compare a "fetched depth" to one from a projection matrix both value need to be in the same "direction", and i feel that it would be unclear to ask people to revert the result from UNITY_SAMPLE_DEPTH because it was already reverted under the hood in that case.
    * finally if one work with non-linear Z (comparing it to a threshold for example) then a #ifdef is thus required, maybe a "Logarithmic01Depth" method could be introduced ? but at that point i feel it less readable than a #ifdef.

    Make senses :) ?

    Florent
     
  3. Kronnect

    Kronnect

    Joined:
    Nov 16, 2014
    Posts:
    2,524
    Thanks for your insights. As a committed publisher I'll keep an eye on these changes and update my assets accordingly but I worry about many assets than will be affected by such breaking changes.
    For instance, I have already modified Beautify so it works with this new reversed zbuffer. As you guessed, it makes comparissons with raw depth values to take some decissions.
    I sticked to UNITY_SAMPLE_DEPTH macro expecting future changes like this one will be obscured behind the curtains. Now I need to have into account this change (no big deal) in the future although it just reads from the read channel of depth texture so this macro has become just boilerplate.

    So was this really required? I would prefer the following approach:
    - Make UNITY_SAMPLE_DEPTH deal automatically with reversed z-buffer.
    - Introduce a new macro called UNITY_SAMPLE_DEPTH_RAW which will simply work as the previous macro.

    Please consider this suggestion while in beta. Thanks.
     
    Last edited: Nov 16, 2016
  4. fguinier

    fguinier

    Unity Technologies

    Joined:
    Sep 14, 2015
    Posts:
    114
    Hi Thrawn75,

    Right, good feedback thanks for it ! It could have been done in that way yes! In fact both approach are probably valid as they brake a different set of use cases, i guess its hard to know what set is the smallest (with and without regard to the asset store) ? However it's unfortunately too late to change that as we are already in the final phase of the beta and a lot of people have already updated there project with the "do not reverse" behavior.

    Florent
     
unityunity