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.
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.
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.
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.
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 :).
Hopefully getting fixed for multiple versions of wherever that bug manifest. So, hopefully not just the newest version of Unity but also older versions?
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.
int screenWidth = camera.actualWidth;
int screenHeight = camera.actualHeight;
if (source.rt.width != screenWidth || source.rt.height != screenHeight)
{
RTHandles.ResetReferenceSize(screenWidth, screenHeight);
}
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.
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.
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.
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: Use custom post-processing with dynamic resolution and DLSS | High Definition RP | 17.0.3.
