Question Optimal usage of temporary RTHandle's after upgrading to URP 14.X

Hi All,

We recently upgraded our development environment to Unity 2022.3.3f1, and subsequently upgraded to URP 14.0.8. We have some Renderer Features that we are currently upgrading to work with the new RTHandle system, but are having some trouble figuring out how to handle temporary RTHandle's.

Before upgrading, we were using

CommandBuffer::GetTemporaryRT(...)

to get temporary render textures, and when we are doing with it we used

CommandBuffer::ReleaseTemporaryRT(...)

to release it.

However, for URP 14 it's recommended to use RTHandles, and so we are now using

RenderingUtils.ReAllocateIfNeeded(...)

to get temporary render textures. However it's not clear how to properly release them. In the example here the RTHandle's are being released only during the Dispose() call, which is not called every frame.

So my question is; is calling

RenderingUtils.ReAllocateIfNeeded(...)

to get a　RTHandle and only releasing it when the RenderPass is Disposed the only way to handle temporary Render Textures?. With this approach, it looks like each Renderer Feature is creating, and then holding onto it's own RenderTexture during it's lifetime. This is a waste of memory and we were hoping to be able to get and release a RenderTexture per Renderer Feature.

Is getting a RTHandle with

RenderingUtils.ReAllocateIfNeeded(...)

, performing some rendering work, and then releasing it immediately during

ScriptableRenderPass::OnCameraCleanup

using

RTHandle::Release()

incorrect?

Kind regards,
James

 

Still haven't been able to figure this out... The documentation is very vague and all the examples I can find in the Unity source code seem to create RTHandles with ReAllocateIfNeeded and hold on to them until Dispose is called...

 

I'm also curious about this and have mostly the same questions plus a few more. I ended up just using the depreciated stuff for now since I at least know how to use them and they aren't causing me issues like the new and very unintuitive methods and objects.