I have a script that needs to render things in world space after post-processing effects.
This works perfectly using a custom HDRP pass with CustomPassInjectionPoint.AfterPostProcess, but not when using dynamic resolution. When dynamic resolution is enabled the render target is scaled up at some point in the post-processing effects stack, which is expected. However, my custom pass still gets a viewport which is only a fraction of the full size.
I believe this is a bug as at this point the viewport should cover the whole screen (or at least the whole part of the screen the camera should render to after being scaled up).
Use a custom pass with CustomPassInjectionPoint.AfterPostProcess
Use dynamic resolution
Render something in the custom pass.
The things will be rendered in a scaled down way in a corner of the screen.
I’ve been encountering this as well on 2021.3.5, though I think I’m only getting it when I use FSR (DLSS disabled) and am forcing a specific screen percentage.
This is a major issue for me, since I don’t want to post-process my UI!
I tried to check if the prior fix for the bug was running, but I was unable to embed HDRP in my project without massive breakage. The code is still there, though.
I guess we should keep this topic alive and on top of the HDRP board, until there is an official response from Unity.
This is a heavy bug, which makes it impossible to combine Dynamic Scaling / DLSS / FSR / TAAU with any custom post processor, or with world space UI (which is also affected, if you use the necessary Custom Pass to avoid blur of fonts).
Funny also that the issue is marked fixed:
and that a PR (which seems to correspond to this issue) is waiting since April in the Graphics repo.
This does not help much, as we use LTS for production. As this is a clear and major bug, it should be listed as known issues on LTS release notes and fixed with high priority. Not sure why this is not the case, as the bug is known since release of LTS (and earlier)
This gets “fixed” when you only see the scene or game view at a time. This bug has been around for a very long time. This plus jittering makes custom pass not very usable in production.
Another bump. New version (2021.3.11), still no mentioning of this major bug, and no resolution. Instead new bugs in the release, leading to instant crash
bump I don’t know what to tell our users anymore about why we don’t fix the bugs with DLSS & co. We are at 2021.3 LTS, DLSS was introduced as a key feature a year ago or more, still not working correctly.
The original problem – where the custom pass would appear scaled-down – is not happening for me in 2021.3.9f1. If I get rid of the fixes introduced here, then the scaled-down rendering returns.
What is happening is that the custom pass is getting clipped based on the render scale. So, if the render scale is at 50%, only the bottom quarter of the custom pass gets drawn at all. The part that is drawn does get drawn at the correct scale.
Custom post-processing volumes that run in the After Post Process step are not affected. I am only seeing problems with custom passes set to run in the After Post Process step.
I’m tinkering around with the pipeline, but I haven’t had any luck making this work correctly yet. If I find a gross hack that makes it work, I’ll post it (:
This resulted in the custom pass getting clipped to a fraction of the screen and getting scaled up. So, at 50% resolution, only the bottom quarter was visible, and the outlines that were getting drawn were doubled in size.
This one resulted in scaling of the effect, but not clipping.
Notice how the outlines are visible all the way to the edge of the screen.
The problem I have been having is not like either of these! Instead, I’m seeing the custom pass getting clipped to the bottom corner of the screen, but it is showing up at the right scale.
This makes me wonder if there is no bug, and that this is just a problem with the custom pass shaders. I do not understand the shaders well enough to say much there, unfortunately.