- Split the Nanite shading pass up into two when outputting velocity during the depth pre-pass: Non-WPO & WPO.
- Add the ability to use an alternate GBuffer layout for given materials to satisfy the output bindings required by the new second Nanite shading pass.
#rb graham.wihlidal, jason.nadro
#jira UE-164554
[CL 22581659 by jamie hayes in ue5-main branch]
We previously refactored some of the code in FSceneTextureExtentState to allow for retaining VR scene textures for VR scene capture (planar reflection) usage, assuming those scene capture extents were smaller than the 'main' VR extents.
In the previous change (12158192), there's logic where the VR extent request will 'grow' if the same VR extent is requested for multiple frames. The thinking might be to get the desired size into the history, but it's not obvious code. This 'breaks' when using a reduced PixelDensity + non-VR SceneCapture. SceneCapture will 'grow' into the bigger texture from history, which will be PD 1.0. The following usage of a sub-1.0 PD VR scene texture (with now a matching extent to the retained stereo extent) will also grow. And when it looks into the history, it will find the PD 1.0 texture, and grow into it, which wasn't the original intent.
<Resize to PD 0.5>
Frame 0 SC - Grow into PD 1.0 VR texture
Frame 0 Main Render - Use PD 0.5 size as extent because stereo history mismatch
Frame 1 SC - Grow into PD 1.0 VR texture still in history
Frame 1 Main Render - Grow into PD 1.0 VR texture because SC retained it in history
The code here has rotted from the VR perspective, and should have further updates. The original logic was meant to manage the interactions between VR main render + VR-enabled planar reflections. We need to account for all non-main render interactions. But we'll defer the bulk of risk to Main.
#jira UE-164414
#rb Arciel.Rekman
#preflight 632be803e23e50651b1ce0ce
[CL 22147123 by robert srinivasiah in ue5-main branch]
Fixed include paths to be relative to the private or public folders.
Hid or removed includes that reached into other private module folders.
Updated PublicInclude paths when necessary.
#jira
#preflight 631a717cec45fbf3d74d4ba7
[CL 21916033 by bryan sefcik in ue5-main branch]
Add PSOPrecache file which wraps engine level PSO structs and functions
- FPSOPrecacheParams used to wrap certain parameters which drive the PSO collection (mostly set from components)
- IPSOCollector interface used as engine entry to the mesh pass processors in renderer project
- FPSOCollectorCreateManager to wrap all statically registered IPSOCollector CreateFuncions
- PSOCollectorStats structs and helper functions
Add PSOPrecache support to PipelineStateCache:
- functions to precache compute and graphics PSOs
- functions to check current precache state
- FPrecacheGraphicsPipelineCache which wraps all currently precached PSOs
IMaterial entry function to PrecachePSOs with given vertex factories and params (implemented by UMaterial & UMaterialInstance) which forwards call to FMaterial and finally the FMaterialShaderMap
- FMaterialShaderMap will iterate all registered IPSOCollector to collect all possible PSOs used and forward them to the PipelineStateCache for actual (async) precaching
RHI Changes:
- Add RHI specific functions to retrieve & compare the FRHIVertexDeclaration and FGraphicsPipelineStateInitializer hash for each RHI
- Add helper functions to match RHI*State data by retrieving initializer
Minimal vertex factory changes for PSO precaching as prep - actual changes in upcoming CLs
MeshPassProcessor base functions to collect PSOs which can be used by all mesh pass processor implemention (actual changes in upcoming CLs)
- Cache complete precache data hash of stored minimal PSO so it can be used for fast actual PSO initializer hash computation (full PSO initializer is build at runtime)
- Cache if minimal PSO was successfully precache and option to skip draw when PSO is still precaching (disabled by default and doesn't work yet via GPU scene based rendering)
- Add helper functions to setup the per mesh pass render target data used during PSO collection
Refactor SceneTextureConfig so it can be initialized from an init struct and move all function to setup the internal members from SceneTexture to SceneTextureConfig using the data from the init struct (so it's available in Engine project)
Fix GBufferInfo format for velocity target (was always floating point while it should be unorm when not android
Make certain helper functions definitions to h file so they can be used everywhere (SupportsNaniteRendering, FTextureRenderTarget2DResource::GetFormat & CreateFlags)
#preflight 63189a5a967ffc68fb9044a5
#jira UE-139584
#rb Mihnea.Balta
[CL 21907508 by kenzo terelst in ue5-main branch]
Previously, we'd call AllocateDepthTexture from every SceneRenderer. Now we gate access with a bit in FSceneTexturesConfig
#jira UE-131060
#rb Arciel.Rekman
#preflight 62be5de0a3568e30668adb63
[CL 20911118 by robert srinivasiah in ue5-main branch]
Clean obsolete codes in mobile postprocess.
#jira UE-156188
#rb Dmitriy.Dyomin
#preflight 62b274f08e5ee14ea77b8d10
[CL 20769595 by Wei Liu 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]
-SceneTextures.cpp was using module lookup functions in the render thread that are only safe to use without locking on the game thread. However we don't want to lock these every frame. So I have added an accessor for this information to IStereoRendering.h and cached the values in the oculus HMD implementation that uses it but did not already have the value cached in the hmd. This cached value can be safely read on any thread.
#review-19621457
#rb Jules.Blok Robert.Srinivasiah
#preflight 624f446f8a43273c43f570f7
[CL 19680731 by Jeff Fisher in ue5-main branch]
