Initialize and manage the RTHandles system

[ShiftedClock_1]

The RTHandles static instance in the CoreRP library requires initialization and management to use. HDRP does this for the user, so it requires no extra effort to use in your own CustomPasses.

In contrast URP doesn’t initialize the RTHandles static instance, making it require extra effort to use.

If URP also initialized and managed the RTHandles static instance it would make porting passes between the two pipelines easier. It also results in less code for the user to manage, reducing the maintenance burden.

I ran into this in the past week while evaluating both pipelines for a project, and it surprised me that URP doesn’t use the RTHandles system in the same way that HDRP does.

[ManueleB]

Hey!
RTHandles support has just landed in URP and will be available in the 22.1 release

for more info on how to upgrade to that version and get full advantage of RTHandles you can check the RTHandles info in the upgrade guide:

com.unity.render-pipelines.universal/Documentation~/upgrade-guide-2022-1.md

[burningmime]

That sounds like 2 days of work for me to update every pass to use that :-(. Other than making it easier to port passes to HDRP, is there any advantage to this over RenderTargetHandles? Seems like just a different name for the same thing.

[rz_0lento]

from PR description:

This PR aims to replace usage of RenderTargetHandle to use RTHandles instead in order to support setting UnityEngine.XR.XRSettings.renderViewportScale in URP.

RTHandle is a SRP core utility class that helps manage unity RenderTexture resources and has DynamicResolutionHandler support. It is currently being used by HDRP and RenderGraph modules. The class also has built-in support for render target dynamic scaling. This will add dynamic resolution support to URP and unifies URP’s render texture management. It also opens the way for URP to integrate with RenderGraph in the future.

Also… this change isn’t removing the previous API just yet, but it will happen in some future version:

The switch to RTHandles is backwards compatible with uses of RenderTargetIdentifiers. This is so users creating their own passes can still have their projects working in the future release. However, we want this compatibility layer to be gone in future versions so that RTHandle dynamic scaling in XR works across the board.

[rz_0lento]

As extra note, I’ve been using URP version with this change merged from Graphics repo directly and none of my existing custom Renderer Features broke because of it, so at least for now the backwards compatibility seems to work just fine.

For my own uses, I don’t actually expect the refactoring work to be that big though. If you look at the changes that RTHandle PR did for URP’s own renderer features or PP, it’s typically few lines change for making it use the new setup.

[daneobyrd]

I really want this to come to URP before URP 13.0. Bring RTHandles to URP 12!

[daneobyrd]

@rz_0lento

As extra note, I’ve been using URP version with this change merged from Graphics repo directly and none of my existing custom Renderer Features broke because of it, so at least for now the backwards compatibility seems to work just fine.

For my own uses, I don’t actually expect the refactoring work to be that big though. If you look at the changes that RTHandle PR did for URP’s own renderer features or PP, it’s typically few lines change for making it use the new setup.

Could you walk me through the steps you took to merge this change from the graphics repo directly? Did you have to use reflection to change the packages?

I see they’ve created a directory for urp.testing that has this change:
https://github.com/Unity-Technologies/Graphics/tree/master/com.unity.testing.urp

[rz_0lento]

@daneobyrd considering RTHandle change is now included on Unity 2022.1.0b1’s URP, that’s the easiest way to give this a go today, no need for custom packages, just install the beta and install urp package from it.

If you really want this to 2021.2, I guess easiest way would be to just see if one can mod current master branch from github to run on 2021.2. There are few API changes but once you find the PRs that did those changes, it’s fairly simple to revert those individual commits.

Also worth noting that Unity is still working on this transition, they have more changes coming in regarding this all the time now, would expect that to keep on going throughout 2022 cycle.

[rz_0lento]

@rz_0lento

As extra note, I’ve been using URP version with this change merged from Graphics repo directly and none of my existing custom Renderer Features broke because of it, so at least for now the backwards compatibility seems to work just fine.

I also have to correct this a bit. Noticed that CopyDepthPass.Setup() now only has RTHandle approach which breaks backwards compatibility if one used this before the change, not sure if this is an oversight or by design, I’ve filed bug report on this (case #1387300).

[ManueleB]

@rz_0lento

I also have to correct this a bit. Noticed that CopyDepthPass.Setup() now only has RTHandle approach which breaks backwards compatibility if one used this before the change, not sure if this is an oversight or by design, I’ve filed bug report on this (case #1387300).

This “breakage” should be as intended, so as stated in the upgrade guide RenderFeatures that used to call SomePass.Setup() in AddRenderPasses() should be fixed by moving those Setup calls in the new SetupRenderPasses override. Does this help in your specific case?

[rz_0lento]

@ManueleB

This “breakage” should be as intended, so as stated in the upgrade guide RenderFeatures that used to call SomePass.Setup() in AddRenderPasses() should be fixed by moving those Setup calls in the new SetupRenderPasses override. Does this help in your specific case?

Ah that was a good point, I’ll take a better look at the official upgrade guide (https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@13.1/manual/upgrade-guide-2022-1.html).

I was just surprised that the remaining backwards compatibility didn’t actually cover whole systems, just the old rt handles… …which alone kinda makes the backwards compatibility less useful in general.

This will have a side effect of many 3rd party URP assets breaking yet again when people move to Unity 2022.

[lingdu_y]

@ManueleB

Hey!
RTHandles support has just landed in URP and will be available in the 22.1 release

for more info on how to upgrade to that version and get full advantage of RTHandles you can check the RTHandles info in the upgrade guide:

com.unity.render-pipelines.universal/Documentation~/upgrade-guide-2022-1.md

Hi, now I just use version 2022.2b, I faced a really awesome problem that I can’t use RenderTargetIdentifier to send “_CameraDepthTexture” into my computer shader, because now there are some format strings behind the original identifier strings just like the picture down.

So how can I get RenderTargetIdentifier from RTHandles, I have read the code in UniversalRender.cs, but I have no idea. I really need your help, thanks.

[ManueleB]

@lingdu_y

Hi, now I just use version 2022.2b, I faced a really awesome problem that I can’t use RenderTargetIdentifier to send “_CameraDepthTexture” into my computer shader, because now there are some format strings behind the original identifier strings just like the picture down.

So how can I get RenderTargetIdentifier from RTHandles, I have read the code in UniversalRender.cs, but I have no idea. I really need your help, thanks.

looks like you are using RTHandle.rt.name instead of RTHandle.name

RenderTargetIdentifier test = cameraDepthHandle.name;  //_CameraDepthTexture
RenderTargetIdentifier test2 = cameraDepthHandle.rt.name;  // _CameraDepthTExture_1348x439_R32_SFloat_Tex2D