Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Question Disabling Antialiasing turns input texture black

Discussion in 'Universal Render Pipeline' started by F4talis, Dec 7, 2023.

  1. F4talis


    Apr 18, 2019
    I've been messing around with some custom post processing shaders in URP 16.0.4. Made some base classes for RendererFeatures and RenderPasses so adding new post processing effects is as easy as a few lines of code, and all works well and good.

    Issue is that whenever I disable antialiasing in the URP asset, my screen turns black.
    upload_2023-12-7_11-42-22.png upload_2023-12-7_11-42-42.png
    Comparison here, first image: AA->2x, second picture: AA->Disabled. (it works on all antialiased settings but disabled)

    I've narrowed it down using my shader's frag function. upload_2023-12-7_11-46-54.png

    As you can see by the commented out lines of code, I've tried a few return values to see what happens.
    Returning float4(1, 1, 1, 0) does in fact turn the screen white, so I know the issue wasn't the alpha as it shows regardless of alpha, which I expected, but there was a thread I read discussing in an old version something to do with antialiasing setting pixels alpha to zero and appearing black.

    I also try immediately returning the colour sampled from the screen, with an alpha of 1( just in case :) )
    This returns black, only with antialiasing disabled. So this implies that with antialiasing disabled, the actual input texture "_BlitTexture" is blank and the shader recieves nothing from the screen.
    The _BlitTexture is what's handled in unity's Blit.hlsl. The RenderPass and RenderFeatures are using the tutorials on Unity's URP 16.0.4 documentation page for "How to perform a fullscreen Blit" and "How to create a custom Renderer Feature".

    This is only my shader testing project, but I'd eventually like to bring these base classes into a game I'm working on, and I don't want to accept the answer of "just keep AA on" because that's not a good programming mentality. I'd just like some insight as to why it's happening.

    I'm not tagging this as a bug because it's likely something I just am not understanding.
  2. F4talis


    Apr 18, 2019
    I've done some troubleshooting now, and the plot thickens.
    I have two base RenderPass scripts, one extends the other. The basic one, is for single pass shaders, and has an RTHandle that is set to the cameraColorTargetHandle of the renderer given to SetupRenderPasses(). It takes that as an input, and calls:
    Code (CSharp):
    1. Blitter.BlitCameraTexture(cmd, targetHandle, targetHandle, material, 0);
    The multipass version, instead holds TWO RTHandles, and using the Configure() override, reallocates those RTHandles using ReAllocateIfNeeded(). Then in the execute method, using a for loop for material.passCount, passes the image back and forth between handleOne and handleTwo (the RTHandles) and eventually passes in back to the cameraTargetHandle.
    This is done using
    Code (CSharp):
    1. Blit(cmd, handleTwo, handleOne, material, i);
    What's crazy is that the multipass version WORKS even regardless of antialiasing being enabled or not.

    I tried changing the Blit() in the single pass version to be simply Blit() instead of Blitter.BlitCameraTexture() and that makes no difference.

    Out of curiosity, I tried in the single pass version, having a temporary RT, blitting the material's pass to the tempRT from the camera, then blitting BACK to the camera from the RT with no material, essentially copying it, and now the screen DOESN'T turn black with antialiasing disabled, giving me the conclusion that the issue for some reason is that Blit(), when antialiasing is disabled, simply isn't allowing me to blit from the camera colour handle back to itself, but it is okay with antialiasing enabled.

    Very strange indeed, and I don't consider this solved, as adding an extra blit pass, ergo another draw call shouldn't be a solution.