Reducing Rendering Cost of Secondary Camera

[Jmangles]

Hi, I’ve been experimenting with effects that require a secondary camera in orthographic form that simply render out a heightmap into a render texture set to like SFoat_16 or 32 format depending on the precision I need.

Despite this second camera rendering only a handful of draw calls with a replacement shader via the Render Objects feature it appears to take just as much time as my main camera on the render thread. It also has a depth pass I totally don’t need.

Is there a way to just do the Render Objects pass with no lighting, no shadows, no depth, no z-buffer or anything?

I was also completely unable to get the custom render texture feature working in order to modify the output heightmap before using it in a material but that’s a different issue.

[Jmangles]

Bumping this thread as it’s still an issue I haven’t been able to solve.

[wwWwwwW1]

I think what you need is Frame Settings (per camera override) in HDRP. You can try submitting an idea on the URP roadmap page.

Also curious to know if there is a way to do this.

[moatdd]

Thought I’d throw my hat in the ring since I’ve been using camera stacking and various pipelines to prototype a lot of post-process effects as well as overlays since the interface is so easy to work with.

But now that the effects look as desired, it’s time to optimize, and after looking in my profiler it seems that although I’m getting ~60FPS I’ve basically blown my budget because optimization is something I don’t do during a prototyping stage since large I add and eliminate large hunks of code before finally deciding to settle down and restructure everything that I’ve developed.

Here’s what my profiler looks like. Obviously, a lot of time is being spent in rendering.

But on closer inspection, it becomes immediately apparent that each one of my overlays that requires a separate camera is taking about as much time to render as the gameplay camera that renders the scene and environment and monsters.

The overlays themselves are hardly complex and render in an instant, but the time it takes to set up and fire off each camera render takes around 1-1.5ms which really adds up!!!

So my main takeaway from URP is that it’s good for rendering complex scenes with a single camera, but you have to be sparing with making a camera render.

They tell us that we should use stacked cameras to do things like render a viewmodel weapon, but it’s important to remember this costly 1-1.5ms overhead penalty.

Some of my post-process effects could be moved into Custom Render Textures to eliminate a camera from the stack, but I’m also rendering my HUD with a stacked camera. I might be able to move that HUD into a Render Objects pass, but I intend on rendering my HUD elements at a resolution that is different from what the gameplay camera is capturing, so I think I might be able to tell that RenderObjects pass to target a different RenderTexture.

Also, I think I can evade rendering separate cameras by just throwing a different view matrix at the currently rendering camera during the Render Objects pass. Basically, I think I can combine everything into a single render pass by overriding camera output target and the view/projection matrices.

It will be ugly and painful but there’s like, 9ms of deadtime I can save.

[moatdd]

Well, I’m going all-in on this. I basically made my own fork of the Render Objects (experimental) Render Feature and this one allows me to specify a secondary camera to pull projection/view matrices from. I also made a “runtime set” as a way to keep track of cameras that may be dynamically loaded/unloaded due to additive levels, which makes it easier for me to reference cameras and a more robust link to these cameras that can be serialized.

My version of the Render Objects also allows for me to override the render target by pointing it to a render texture of my choice. With these two features, I can avoid having to create separate render pipelines for each camera, instead using my Custom Render Objects Feature.

So far it’s working but man, it means that it’ll be a VERY long render pipeline and difficult to keep organized. That’s the sacrifice that must be made in the name of performance.

[moatdd]

The main thing I foresee myself running into will be post-process effects that need to be applied to specific render textures for things like minimaps or picture-in-picture displays.

I’m literally going to have to edit the code of all these effects to run ConfigureTarget() to redirect them to the render textures. This is awfully cumbersome.

URP is great if you have only one camera to see the world from and a lot of little objects that can all be done as one render, but if you have to render many additional cameras that display only a few things each, then the overhead of individual camera rendering will kill your framerate.

[moatdd]

Creating the custom render objects render feature that allows me to choose a different camera from the one that’s rendering turned out to work very well, as did combining it with custom render textures and I managed to lop about 8ms off of my render time.

The current problem I’m facing, however is that it’s difficult to get the correct culling from the different camera.

[stonstad]

Just circling back on this thread. Has anything improved in URP with regard to camera stacking performance (vs built-in)?

[rafael_lima83]

Well, considering someone bumped this thread…

Is stacking cameras the best way to sort order drawing on URP? I see a similar effect here, I’m still getting an acceptable performance, but I lose like 2.5-3.5 ms per frame just for stacking cameras, even when they aren’r rendering anything. It seems to be a lot. I really need to have layers for different stuff here, and all official documentation says I should use stacked cameras for this.

But the overhead seems to be really heavy for what is basically just a layer sort thing.