This also implements r.Translucency.ScreenPercentage.Basis to experiment controling the translucency resolution independently from the primary screen percentage
#rb none
#jira UE-152560
#preflight 6294fbc4e61254772f5834a6
#ROBOMERGE-AUTHOR: guillaume.abadie
#ROBOMERGE-SOURCE: CL 20432059 via CL 20432067 via CL 20432069
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v949-20362246)
[CL 20434142 by guillaume abadie in ue5-main branch]
* When RT debug is enabled we disable translucency but some of the postprocessing materials might use that texture so we need to set correct ViewRect as well.
#jira UE-144066
#rb Tiago.Costa
#preflight 6290d21ad24a7fc585f2c9f4
[CL 20429352 by aleksander netzel in ue5-main branch]
This improves how the editor deals with displays that have different capabilities (some with HDR, others without).
Centralize where the CVars are accessed
Have the swapchain created in SDR when shown on a SDR display
Make sure color gamut matches the one supported by the platform/swapchain.
Allow Movie scene capture to override the gamut/output format to keep existing behaviour (MovieSceneCapture relies on swapchain data)
#preflight 628baef5183c1e13462a504d
#jira UE-150952
#rb luke.thatcher
[CL 20347067 by benjamin rouveyrol in ue5-main branch]
- this was working around a system level issue but we no longer support the older SDK versions which had the issue on the impacted platform
- testing
- ran QAGame TM-DepthOfField on impacted platform as DoF was one of the passes which previously incurred the issue
#rb David.Harvey
#jira UE-124865
#preflight 62631b1d00654785f436a2c8
[CL 19902059 by eric mcdaniel 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]
Requrements:
iOS: A8+
Android VK: more than 4 color attachements, more than 4 input attachments
Android GL: Unsuported - PLS seem to be limited to 128bits on most devices
#rb wei.liu
#preflight 625f866b9c09ef439db7612b
[CL 19861367 by Dmitriy Dyomin 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]
