By default Lumen is disabled for Scene Capture to save memory, but can be enabled via post process override settings. The memory usage display was important when adding this feature, to give feedback to the user of the memory impact for enabling Lumen. It's also just generally useful besides. Lumen costs 340 MB to enable if view specific Lumen scene data is enabled at low quality (half resolution page buffer), or 640 MB at high quality (full resolution page buffer). Besides memory statistics in the Texture Editor, there is an editor specific command which dumps per-resource sizes to log (r.SceneCapture.DumpMemory), useful for investigating where the memory is going.
Lumen requires persistent state to function properly, so Lumen is disabled if bCaptureEveryFrame and bAlwaysPersistRenderingState are both false. I decided not to allow Lumen for Scene Capture Cube, due to high memory cost, poor CPU performance, and lighting seams across the faces. I'm hoping in the future to run Scene Capture Cube as a single scene render call (effectively 6-way split screen for the 6 cube map faces), and have certain rendering passes run as a single omnidirectional pass. Perhaps Lumen could use a single radiance cache for all 6 faces, rather than 6 separate caches, reducing memory, significantly improving performance, and hopefully solving lighting seams.
I rounded out the set of functions that handle per-view VSM and Lumen caches, to include functionality to remove the caches (necessary to allow the per-view Lumen cache to be toggled back off), and query their presence.
#jira UE-148665
#rb Krzysztof.Narkowicz Daniel.Wright zach.bethel
#preflight 6307cf561615ec0db52700e3
[CL 21594503 by jason hoerner in ue5-main branch]
Focus started on GenerateMips and AddClearUAVPass.
#jira none
#rb mihnea.balta
#preflight 62fe768d200ff87e07c5e1ad
[CL 21448320 by christopher waters in ue5-main branch]
- Ported remaining ISceneViewExtension calls to RDG.
- Removed several empty override passes being added to the graph.
- Merged two graphs into one.
#preflight 62c4c61a2a05d4f55bd5912f
#rb luke.thatcher
[CL 20971717 by zach bethel in ue5-main branch]
2. Supports CustomDepth in translucency pass on mobile LDR.
#jira none
#rb Dmitriy.Dyomin
#preflight 62be9894d94b57687c68aed1
[CL 20911586 by Wei Liu in ue5-main branch]
- Removed scene render mem-mark among others. MemStack usage is now restricted to local scopes with known marks.
- Render resources with destructors are allocated using the FSceneRenderingBulkObjectAllocator on FSceneRenderer, which is deleted when the scene render is.
#preflight 62b266e20d4d6228de97babe
#rb mihnea.balta, yuriy.odonnell
[CL 20907647 by zach bethel in ue5-main branch]
* Each cube map face gets its own FSceneViewState. The downside is that it potentially could add a lot of extra memory. So some memory optimizations were made to compensate.
* Global distance field data is shared for all cube map faces. This data is only dependent on the view origin, which is invariant for the cube map faces. A mechanism was added to allow cross view state data sharing for shared origin views. This saves 8.5 MB, and improves perf.
* Disabled distance field lighting temporal AO for cube map capture. The AO history texture in the view state is dependent on the Scene texture extents, which is typically the front buffer size, which then gets multiplied by 6. For a 1080p front buffer, this is 24 MB, while for a 4K front buffer, this is 96 MB, regardless of the resolution of the cube map capture itself. A 256x256 cube map capture, including all the auxiliary state, is otherwise only around 9 MB, so this is an order of magnitude increase. A comment in the function "DistanceFieldAOUseHistory" has more details on how this could be fixed, by using the view rect rather than Scene texture extents for the history texture -- for the 256x256 case, it would reduce the incremental memory cost to 768K.
With the memory savings from disabling distance field lighting temporal AO, this change is more or less memory neutral if the Scene texture extent (front buffer) is 1080p. A net increase of 590K. With a higher resolution front buffer, it's a subsantial memory win.
#jira UE-151717
#rnx
#rb tiago.costa daniel.wright
#preflight 629f6a27233ae0a8f8f99932
[CL 20614815 by jason hoerner in ue5-main branch]
The refactor to get rid of the FSceneTextures and FSceneTexturesConfig global singletons has also been preserved. The FViewFamilyInfo is used to hold those structures, so client facing API functions that lack a scene renderer reference can still pull the FSceneTextures[Config] from the view family pointer. All other scene renderer state has been moved from FViewFamilyInfo back into FSceneRenderer.
#jira none
#rnx
#rb ola.olsson krzysztof.narkowicz zach.bethel
#preflight 629f770e233ae0a8f8fb7f2e
[CL 20540730 by jason hoerner in ue5-main branch]
* Existing calls to CreateSceneTextureShaderParameters and similar functions use "GetSceneTexturesChecked", which allows for the possibility that they are reached in a code path where scene textures haven't been initialized, and nullptr is returned instead of asserting. The shader parameter setup functions then fill in dummy defaults for that case. The goal was to precisely match the original behavior, which queried the RDG blackboard, and gracefully handled null if scene textures weren't there. This definitely appears to occur in FNiagaraGpuComputeDispatch::ProcessPendingTicksFlush, which can be called with a dummy scene with no scene textures. In the future, I may change this so dummy defaults are filled in for FSceneTextures at construction time, so the structure is never in an uninitialized state, but I would like to set up a test case for the Niagara code path before doing that, and the checks aren't harmful in the meantime.
* I marked as deprecated global functions which query values from FSceneTexturesConfig, but they'll still work with the caveat that if you use multi-view-family rendering, the results will be indeterminate (whatever view family rendered last). There was only one case outside the scene renderer that accessed the globals (depth clear value), which I removed, noting that there is nowhere in the code where we modify the depth clear value from its global default. I would like to permanently deprecate or remove these at some point. Display Cluster is the only code that's currently using the multi-view-family code path, and as a new (still incomplete) feature, third party code can't be using it, and won't be affected.
#jira NONE
#rb chris.kulla zach.bethel mihnea.balta
#preflight 6261aca76119a1a496bd2644
[CL 19873983 by jason hoerner in ue5-main branch]
* Added "BeginRenderingViewFamilies" render interface call that accepts multiple view families. Original "BeginRenderingViewFamily" falls through to this.
* FSceneRenderer modified to include an array of view families, plus an active view family and the Views for that family.
* Swap ViewFamily to ActiveViewFamily.
* Swap Views array from TArray<FViewInfo> to TArrayView<FViewInfo>, including where the Views array is passed to functions.
* FSceneRenderer iterates over the view families, rendering each one at a time, as separate render graph executions.
* Some frame setup and cleanup logic outside the render graph runs once.
* Moved stateful FSceneRenderer members to FViewFamilyInfo, to preserve existing one-at-a-time view family rendering behavior.
* Display Cluster (Virtual Production) uses new API.
Next step will push everything into one render graph, which requires handling per-family external resources and cleaning up singletons (like FSceneTextures and FSceneTexturesConfig). Once that's done, we'll be in a position to further interleave rendering, properly handle once per frame work, and solve artifacts in various systems.
#jira none
#rnx
#rb zach.bethel
#preflight 625df821b21bb49791d377c9
[CL 19813996 by jason hoerner in ue5-main branch]
* For thumbnail renderers, the prototype of RenderViewFamily (which is called by all the types of thumbnail renderers) has been changed to take a non-const FSceneView* parameter (so that SetupView can be called on it) and the various GetView functions have been renamed CreateView since it more accurately depicts what the functions do (plus they return the non-const view they've created)
* UGameViewportClient::Draw was calling SetupViewFamily but not SetupView
* Made sure FSceneRenderer::ViewExtensionPreRender_RenderThread is called right before RenderThreadBegin for all code paths
* Made sure view extensions are gathered for all code paths rendering a view family
Note: BeginRenderViewFamily (i.e. game-thread), PostRenderView_RenderThread and PostRenderViewFamily_RenderThread are still not called on the non-standard code paths
#jira UE-140273, UE-140489, UE-139067, UE-140425
#rb sebastien.lussier, rob.srinivasiah
#tests EngineTests (screenshots), editor
#preflight 61fd216ae17efe76d1b49a2d
#lockdown mihnea.balta
#ROBOMERGE-AUTHOR: jonathan.bard
#ROBOMERGE-SOURCE: CL 18884880 in //UE5/Release-5.0/... via CL 18884941 via CL 18885221
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v910-18824042)
[CL 18885607 by jonathan bard in ue5-main branch]
This changes allow to bind a larger amount of rect. light texture, and allows future support for rect light in forward & cluster passes.
#jira none
#rb sebastien.hillaire
#preflight 61fcebd0b5092d45ad110db4
[CL 18861192 by Charles deRousiers in ue5-main branch]
