This logic took primitives with a material using static lighting and moved velocity writing to a second pass.
Seems like that is some old behavior and after asking around it isn't well known why we had it.
Anyway it's not good to pay the cost of that second pass, so removing that.
#preflight 628fd8f574630984fd4d4464
#ROBOMERGE-AUTHOR: jeremy.moore
#ROBOMERGE-SOURCE: CL 20392160 via CL 20392172 via CL 20392182
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v949-20362246)
[CL 20398501 by jeremy moore in ue5-main branch]
- Decals materials are evaluated using callable shaders in PathTracingKernel.
- Decals are culled using a 2D grid similar to the existing light grid.
- In order to correctly handle decal blending order, decals are sorted using the same logic as the rasterizer on CPU. The compute shader that builds the decal grid maintains the correct order.
- Decal materials are wrapped in FRayTracingDecalMaterialShader. The instance parameters of each decal are bound using uniform buffers.
#preflight 628f3fed2f2409bc1e7a6414
#rb Yuriy.ODonnell, chris.kulla, Jeremy.Moore
[CL 20377336 by tiago costa in ue5-main branch]
- FRHIRayTracingScene is created with NumCallableShaderSlots.
- Application can add entries to SBT using CallableCommands array.
- ShaderBindings are generated from CallableCommands in BindRayTracingMaterialPipeline(...) once the RTPSO is available so CallableShaderIndex is known.
- Shader Bindings are then merged and set during WaitForRayTracingScene.
#rb yuriy.odonnell
#preflight 628d4053b378b39d419afc4d
[CL 20356249 by tiago costa in ue5-main branch]
Promote OnGetOnScreenMessages delegate from private to protected so that all derived renderers from SceneRenderer can add screen messages without modifying the header.
#jira UE-152824
#preflight 628d3a697a34ff0c891f7cac
#rb Tiago.Costa
[CL 20355433 by Tiantian Xie in ue5-main branch]
Remove unecessary mutable type qualifiers from FMeshProcessorShaders.
#rb yuriy.odonnell
#preflight 628cf1e17778f10598b1e011
[CL 20349077 by tiago costa in ue5-main branch]
- Buffers allocated using RDG.
- Use TRDGUniformBufferRef instead of TUniformBufferRef to be able to include SHADER_PARAMETER_RDG_BUFFER_SRV inside the uniform buffer.
#rb yuriy.odonnell
#preflight 628ba79c573a7de2c427c332
[CL 20330573 by tiago costa in ue5-main branch]
* Change LumenVisualize to support inline ray tracing.
* Add BuildLumenHardwareRayTracingMaterialBindings to build bindings when shader pipelines are disabled.
* Pass RayTracingSceneMetadata to all Lumen shaders to be able to reconstruct WorldNormal.
* Fix CardPageLastUsedBuffer to not use GWhiteVertexBufferWithRDG which is not a structured buffer.
#rb yuriy.odonnell, krzysztof.narkowicz
#preflight 6288d03b6f11ac6727a043c9
#ROBOMERGE-AUTHOR: aleksander.netzel
#ROBOMERGE-SOURCE: CL 20321027 via CL 20321048 via CL 20321071
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v948-20297126)
[CL 20322446 by aleksander netzel in ue5-main branch]
#ROBOMERGE-AUTHOR: daniel.wright
#ROBOMERGE-SOURCE: CL 20231807 via CL 20231873 via CL 20231883
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v943-19904690)
[CL 20233549 by daniel wright in ue5-main branch]
- Also added a view event for better UX.
- Also a speculative fix for the non-Nanite instance culling.
#rb Rune.Stubbe, Rob.Srinivasiah
#review @Rune.Stubbe, @Robert.Srinivasiah
#jira UE-151478
#preflight none
[CL 20133378 by Arciel Rekman in ue5-main branch]
* Fence wait for cross GPU resource transfers can now be deferred. Moved the wait for view family render target transfers to the end of all view family rendering. Saves a few ms GPU in stalls in the Valley project. The fence wait is marked with a different GPU stat scope, so it can be differentiated from the transfer workload.
* Ray tracing scene update now runs once, for the first view family only. Saves around 1.2 ms GPU when three views are present.
* Added logic to sort the largest view families to run first, which tend to be the inner frustum, and are usually the bottleneck for the entire frame. This improves scheduling, saving around 1.0 ms GPU.
* Avoid CPU stalls where Render Thread waits on RHI Thread, by only running "SetFlushResourcesRHI()" on the first view family. Can save multiple ms when CPU bound.
This is part of ongoing multi-view-family scene render refactor work, where these improvements were made possible by the refactor.
#jira none
#rnx
#rb zach.bethel jason.nadro
#preflight 6272cef4ec1566a7062f20c4
[CL 20059593 by jason hoerner in ue5-main branch]
- raytracing instance culling doesn't apply far field offset to view origin (FRayTracingCullPrimitiveInstancesClosure::operator()).
- also don't need to refresh cached raytracing instances when far field offset changes anymore.
#preflight 6273d7e46a646b1d153e8e7d
#rb Patrick.Kelly
[CL 20057351 by tiago costa in ue5-main branch]
- Updated places accessing TLAS SRV to use ERayTracingSceneLayer::Base
#rb yuriy.odonnell
#preflight 62728a70ec1566a70616ac9a
[CL 20041705 by tiago costa in ue5-main branch]
Previously FScene contained an array of RT-shadowed lights which was updated when a light is added/removed.
However, this is incorrect as the light RT shadow state depends on CVars that may be changed dynamically.
The solution is to check if the scene currently contains any RT-shadowed lights during rendering. This is more expensive but robust.
The array of RT-shadowed lights is removed as it was not used beyond checking if it's empty.
#rb juan.canada
#preflight 6271aa653e1f2a9d3a4dd84c
[CL 20041248 by Yuriy ODonnell in ue5-main branch]
- Each layer corresponds to a separate TLAS.
- Values returned by FRHIRayTracingScene::GetSizeInfo() are large enough to contain all layers.
- Higher level code can use FRHIRayTracingScene::GetLayerBufferOffset(...) to query the offset of individual layer TLAS when building SRVs.
- Updated FRayTracingSceneInitializer2 so higher level code specifies how many instances are in each layer.
#rb yuriy.odonnell
#preflight 62714094e16e280be60fc35c
#jira none
[CL 20025952 by tiago costa 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]
