Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Bug Custom Post Process issues

Discussion in 'High Definition Render Pipeline' started by OlavAketun, Oct 5, 2023.

  1. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    I'm not sure if anyone has encountered this before, but it seems custom post processing effect do not align scale with the sceneview nor any camera until you've entered playmode.
    Changing the window size of the sceneview or the resolution in gameview breaks it again.

    Here the custom post process is off:
    1 custom post processing off.JPG

    And here it's on:
    2 custom post processing on.JPG

    Entered playmode, it aligns with view:
    3 entered playmode.JPG

    Changing the resolution breaks it again:
    4 changed resolution.JPG

    I fear this is a bug in the method Render, where the RTHandle source and/or destination bugs out when trying to set the render resolution to lower than what it already was. Going from 512x512 to 1024x1024 works fine, but going back down again screws up the scaling and it's borked.
    Talking about this part of the custom post process:
    https://docs.unity3d.com/Packages/c....CustomPostProcessVolumeComponent.Render.html

    If we try to log the width and height of the rendertexture used by RTHandle source or destination we can see it clearly doesn't get the resolution correctly.
    Doing a debuglog as the very first thing we do as the render starts.
    Debug.Log($"{source.rt.width}, {source.rt.height}");

    It will log the new change from a lower resolution to a higher resolution, but not the other way around.

    Using HDUtils.DrawFullScreen works if the shader is set up correctly, it will scale properly to the set resolution.... Buuuut now it ignores all the other post processing effects in my volume.
    I can't win.
    Either work with something broken or work with something that is also broken.

    Multiplying my texture coordinates with _RTHandleScale won't work when it doesn't even update its own scale.
    _RTHandleScale found here:
    https://docs.unity3d.com/Packages/c...@14.0/manual/Custom-Pass-Troubleshooting.html
     
    Last edited: Oct 9, 2023
  2. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    This bug is present in the alpha of 2023.3, so I suspect this is something that has gone under the radar for a loooong time.
    That Render method is just broken. It's probably better to just set up my own at this point.
     
  3. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    Temporary fix would be to reset the reference size using RTHandles.SetReferenceSize
    and simply check if source.rt width and height is the same as camera.actualWidth and height, if not then reset the reference size to the same as camera width and height.
    It works, but it's kinda wonky and requires a frame to reset the size on my machine.
     
  4. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    788
    Hey, thanks for reporting this, if you can by any chance log a bug using the Editor with all this very useful information, I'm sure it will be fixed rather quickly :).
     
  5. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    I have done that now. Case IN-57088.
     
    chap-unity likes this.
  6. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    788
    Thanks a lot :)
     
  7. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    Any status on the bug? I believe you guys named if "RTHandle does not scale down when scaled up" in your internal workflow.
    Fixed? Wont Fix?
     
  8. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    788
    It has been confirmed on our side and will surely be fixed in the next few weeks.
    Thanks for your patience :)
     
  9. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    Hopefully getting fixed for multiple versions of wherever that bug manifest. So, hopefully not just the newest version of Unity but also older versions?
     
  10. chap-unity

    chap-unity

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    788
    yes, if it's broken on previous ones, it can be backported to 2021.3 LTS
     
    OlavAketun likes this.
  11. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    Welp, this issue is now marked as "closed" and resolution given "As Designed".
    Designed to be broken it seems. Fine by me, it only means the documentation is lacking and must be updated to account for this problem.

    I suggest adding this to the example script render method, if its designed to be using CommandBuffer.Blit:
    It's a hacky solution to a 'by design' broken problem.
    Code (CSharp):
    1.  
    2.         int screenWidth = camera.actualWidth;
    3.         int screenHeight = camera.actualHeight;
    4.      
    5.         if (source.rt.width != screenWidth || source.rt.height != screenHeight)
    6.         {
    7.             RTHandles.ResetReferenceSize(screenWidth, screenHeight);
    8.         }
    9.  
    Else I would redo the example to use HDUtils.DrawFullscreen and the correct blend mode.
    Or just redo the documentation to use the shadergraph if you guys don't want people to write their own shaders.
     
  12. Julien_Unity

    Julien_Unity

    Unity Technologies

    Joined:
    Nov 17, 2015
    Posts:
    73
    Hi, I'm the one who closed the issue.
    Have you read the resolution notes? I provided all the implementation details to make your custom post process work. If anything there is unclear please let us know.
     
    chap-unity likes this.
  13. OlavAketun

    OlavAketun

    Joined:
    Aug 4, 2021
    Posts:
    58
    Yes, obviously I read the email, and obviously I've gone through the documentation as well... Your solution was pretty much what I expected:
    Use shadergraph and HDUtils.
    But it doesn't help that the documentation (that you linked and I based everything on) is lacking, misleading and contradictory to the resolution you brought. The example script is using the broken method, and it's not using shadergraph after all.

    On the bright side, it does work now using shadergraph.

    But writing in the resolution that I'm using the wrong API when the documentation is using another.... That really irks me badly.
    I followed the docs, I even went a step deeper and found a hacky workaround for the method used in the docs. But then I'm told I did it wrong, and I'm supposed to do something completely different... That's annoying.

    Don't take it the wrong way, I'm not angry or annoyed at you. I'm angry at the process.
     
  14. Julien_Unity

    Julien_Unity

    Unity Technologies

    Joined:
    Nov 17, 2015
    Posts:
    73
    Hey,
    I'm going to try to clarify a few things.

    First regarding the documentation, you were right that the example is not correct and we are fixing it as I'm writing this message.
    The reason why HDUtils.DrawFullScreen is recommended over Blit is that HDRP uses the RTHandle system internally which will result in rendering being potentially in a sub viewport of the internal render targets. This also has an impact when sampling those textures since the UVs need to be scaled accordingly.
    Blit does not know about this system and so will just blit inside the full target render target, which might be wasteful and produce stretching artefacts. DrawFullScreen on the other hand will properly setup the viewport prior to rendering the full screen quad.
    One of the other points to clarify is that Shader Graph is not mandatory to write those passes. The helper node I mentioned previously just does the scaling of UVs for you so you don't have to care about the implementation details. However you can still write your shader and scale the UVs yourself like described here for example: https://docs.unity3d.com/Packages/c...-post-processing-dynamic-resolution-dlss.html.

    I hope this clarifies things further.
     
    chap-unity likes this.