RT Memory Spike when water bodies MarkForRebuild() due to ViewFamily extent resize

Development World Creation
, ,
1

Hello,

We have a large open world with a Water Zone that covers a large area and has a resolution of 2048x2048. With World Partition set up, when some areas are streamed in, this causes a MarkForRebuild() in the WaterZoneActor which triggers a Custom Render Pass for the frame to recalculate the WaterInfo.

What I am seeing is that when this Custom Render Pass is triggered, new Views are injected into the Scene’s ViewFamily. Later on, `SceneRenderer::GetDesiredInternalBufferSize` uses the maximum extents of all Views in the ViewFamily to determine the size of the scene render textures, which causes our RTs for such systems as Lumen Reflections and others to be bumped up in resolution for the frame (Our normal Scene resolution is 2304x1296, 4K@0.6 screen percentage -- so in those spike frames the RTs are bumped up to 2304x2048 due to newly injected WaterInfo Views in the ViewFamily having 2048x2048 extents).

From my understanding, this WaterInfo Custom Render Pass is a completely auxiliary offscreen process using it’s own orthographic projection and requiring none of these affected Lumen or other resources that are used for normal screen rendering. Thus I am wondering if it is normal for our scene view extents to be bumped up based on the Water Zone resolution when they are MarkedForRebuild, and if not, what type of solution would you recommend to avoid these spikes ?

I have tried setting r.Water.WaterInfo.RenderMethod=1, and in fact this solves the spike. Although I have read elsewhere that this method will be deprecated. Also, setting the WaterZone resolution to lower than the screen resolution alleviates the spike completely as well -- but this is something we’d like to avoid.

Please let me know if there’s anything I can provide to be more clear with my issue ! Thanks

2

Hi Benjamin,

you hit the nail on the head with your description of the issue. We’re aware of the problem and have in fact run into it ourselves from time to time. The basic idea behind CRPs was to avoid the overhead of SceneCaptures and inline rendering of auxillary views into the main view. Unfortunately, this currently assumes that whatever rendertarget your targeting has a resolution <= the main view resolution. We’ll definitely have to fix this one but in the meantime, you can use RenderMethod=1. We won’t remove it until the CRP based method is working more predicable in this context.

There’s also the option of using the local tessellation mode on the water zone. We’ve introduced this for large open worlds with streaming and the way it works is that you have a smaller sliding window around the player and it internally rerenders the WaterInfoTexture only for this smaller window. You can then use a lower resolution, fixing the issue as well.

I’m sorry I don’t have better news, but rest assured that this is an issue that has come up several times before, so the pressure to fix it is on :slight_smile:

Best regards,

Tim