Feature Request Initialize and manage the RTHandles system

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.

 

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.

 

from PR description:

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

 

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.

 

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

 

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

 

@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.

 

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).

 

Ah that was a good point, I'll take a better look at the official upgrade guide (https://docs.unity3d.com/Packages/c...iversal@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.

 

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.