- Deprecated FRayTracingMeshResourceCollector and FRayTracingMaterialGatheringContext.
- Instead GetDynamicRayTracingInstances(...) implementations should use the new FRayTracingInstanceCollector which extends FMeshElementCollector with ray tracing functionality (AddRayTracingInstance/AddReferencedGeometryGroup/AddRayTracingGeometryUpdate)
- this is similar to GetDynamicMeshElements(...) using FMeshElementCollector.
- FRayTracingInstanceCollector uses a dedicated RHI command list to gather instances, which is different than FRayTracingMaterialGatheringContext which used the immediate command list.
- Moved dynamic instance gathering logic in RayTracing.cpp into a new class FDynamicRayTracingInstancesContext laying the foundation of gathering dynamic instances in parallel threads on follow up changes.
#rb Kenzo.Terelst
[CL 36034312 by tiago costa in ue5-main branch]
Static SkyLights do not require it. For stationary and movable skylights r.SupportStationarySkylight has to be enabled or pre-computed lighting disabled in a project.
In a scenes without SkyLight actor - shaders will still include skylight diffuse condtribution code, however will apply a zeroed color.
[CL 35447934 by dmitriy dyomin in ue5-main branch]
Unlike local merge (landscape.EditLayersLocalMerge.Enable 1), batched merge is backwards-compatible with BP brushes and will therefore replace both global merge and local merge in the near future. However, in order to maintain full backwards-compatibility, existing BP brushes will still act as they do now wrt determinism, requiring the entire world to be loaded by default. This means that as long as a landscape uses existing and not-yet converted brushes like Landmass, Water, etc., it will effectively act as global merge, with the same memory constraints as the current ones.
It also supports both vertical (in between edit layers) and horizontal (in between paint layers) blending, which allows legacy weight-blending to still work but opens up several possibilities in term of paint layers blending improvements.
Details:
* ILandscapeEditLayerRenderer is an interface (UInterface, actually) to implement for any element that needs to write heightmaps/weightmaps/visibility maps. These can be anything (edit layers, BP brushes, actors, components, ...), which streamlines the rendering/blending capabilities while maintaining backwards-compatibility
* UE::Landscape::EditLayers::IEditLayerRendererProvider is an interface to implement in order to provide a sequence of ILandscapeEditLayerRenderer to the landscape. This will be called on-demand when merging the landscape, which means the landscape dynamically retrieves its active renderers instead of relying on the landscape actor's data to do so. This solves the issue of having to checkout the landscape when adding/removing an element (e.g. a BP brush) to it. BP brushes are still supported, but things like landscape patch components can now be trivially added to a sequence of render operations without checking out the landscape actor
* The merge operation is now generic and is split into several render batches (instead of one large render, the size of the entire loaded landscape), hence the name. Each batch is sized automatically so that it contains a minimal amount of weightmaps and a minimal amount of landscape components.
* A component dependency analysis is run in order to maximize the amount of components to render in a given batch while trying to respect the optimal batch size (CVar landscape.EditLayersLocalMerge.MaxResolutionPerRenderBatch, default value : 1024) If a given component depends on components outside the batch, though, it will either be rendered in another batch (if possible) or the batches will be made large enough to render these (which allows the system to be compatible with existing BP brushes such as Water, but also prevents batched merge to solve the GPU memory requirements that global merge has)
* The merge is split into the following phases :
1. Retrieval of edit layer renderers and their associated states for the various merge types (supported/enabled for heightmaps/weightmaps/visibility)
At this point, the user can selectively change the enabled state of the supported renderers, which allows to customize the merge operation without mutating the landscape state (e.g. only keeping the layers under edit layer N enabled)
2. Trim the unneeded renderers for the requested merge operation (disabled renderers, unneeded weightmaps, etc.)
3. (weightmap merge only) Analyze the renderers' weightmaps usage and divide the renders into several "render groups", that is, a set of weightmaps rendered together because they have a(n horizontal) dependency. Each render group will be rendered separately (i.e. reduces the memory requirements of weight-blending to the minimum)
4. Each renderer provides a list of "render items", which contain locality information (where does this render item outputs data? what input data does it require? does it output heightmap/weightmap/visibility? what weightmap(s) does it output?) and a full component dependency analysis is then run on all renderers/requested components
5. The work is split into several batches, each batch into several render steps : for each render group, there's one step per active renderer, and one last step : a simple callback, which the user can attach to, which allows to retrieve the data that has been rendered for this render group for this batch, i.e. a portion of the merge landscape data, before the render target it was using gets repurposed for another batch/render group.
Currently, this is where the readback of heightmaps/weightmaps to the final texture is done and eventually, the same merge can be repurposed by using another callback and, for example, copying into a transient render target (partial renders), or an image on disk (partial exports)
6. The list of render batches and render steps is executed. Some renderers are automatically added to mix (e.g. default data rendering, to provide the initial clear, at the beginning, and "legacy" weight-blending and normals rendering, both at the end of the merge process) and each batch also has a list of "validity" render targets (one per target layer), which is nothing else than a binary "stencil" buffer, masking the components that are *not* in a given batch. These are not implemented as stencil buffers, though, because we eventually might need access to them on the BP side, so they are plain UTextureRenderTarget2D.
* Several CVars (landscape.BatchedMerge.VisualLog.*) were added to help debug the merge process
* In order to improve rendering time, a new utility shader (CopyQuadsMultiSourcePS) was made to copy several (up to 63) source textures into an atlas, which optimizes quite a bit the edit layer->atlas copy operation
Misc changes:
* Improvements/fixes to landscape-related GPU tags
* Fixed landscape.DumpWeightmapDiff which would leave txt/png files for weightmap allocations that haven't actually changed if one of the other channels of the weightmap had some data changes
Code details:
* OnFullHeightmapRenderDoneDelegate has been replaced with OnEditLayersMerged and is now called for each batch render
* Non-public API landscape utils have moved to LandscapeUtilsPrivate.h/.cpp
* Fixed edge case of a map that was saved with an invalid ULandscapeEditLayer (e.g. after having uninstalled a plugin where the base class of a layer was defined): we now clear the layer and make sure we don't fall into a situation where there's no edit layer altogether (which is not allowed and usually enforced by the UX)
* Added parameter to ReallocateWeightmaps in order to restrict the re-allocation of weightmaps to a given set of components. This is to avoid a situation where we're trying to add weightmap allocations to components that are not part of the merge. This will eventually go away when we refactor the weightmap allocation system in the editor
* Since the whole thing has to run on the game thread (because of BP calls), a new "scratch render target" system has been added (ULandscapeEditResourcesSubsystem / ULandscapeScratchRenderTarget) in order to help the various merge steps to request/release URenderTargets (2D and 2D array) and manage their RHI access. This would normally be done via RDG but we don't have access to it outside the render thread. This is shared across landscapes, which minimizes the amount of render targets needed when editing multiple landscapes at the same time.
#rb chris.tchou
#jira UE-214800
#tests Editor, cooked game
[CL 35108473 by jonathan bard in ue5-main branch]
The first issue is solved by making RenderBasePass static, so it doesn't have access to the main ViewFamily member of the scene renderer, and instead pulls the view family from the first view passed in. The second issue is solved by dividing calls to the "GetDynamicMeshElements" virtual function by view family, so the correct ViewFamily is sent to each call. The view visibility bits are masked for the subset of views with a given family. This approach avoids the need to change the API and refactor many implementations to be aware of multiple view families. A handful of GetDynamicMeshElements implementations include logic that can't be run more than once. To handle that case, the flag bSinglePassGDME was added to fall back to the original single call behavior, with the assumption that the implementation must properly handle variations in the Family pointer between Views. A pass was made over all 100+ GetDynamicMeshElements implementations, with these edge cases found and handled:
* FMaterialSpriteSceneProxy and FEditorWidgetBillboardProxy each share a single set of vertex buffers across all views.
* FLandscapeComponentSceneProxy includes an LOD frame dump feature, which should only run once.
* FModelSceneProxy has a bAnySelectedSurfs flag accumulated across all views.
* UE::XRCreative::Private::FRenderComponentSceneProxy::GetDynamicMeshElements consumes cached geometry generated over the previous frame.
* FWaterMeshSceneProxy::GetDynamicMeshElements uses all Views together to compute visible water tiles. Running in a single call requires wireframe status to be determined per view.
No edge cases were found in the GetDynamicMeshElements implementations in a large in-house project using the engine, and behavior only changes if a new feature (Custom Render Passes) is in use, so hopefully it should be rare for other third party projects to encounter issues.
As a separate optimization, force the "Lighting" flag to always be set for Custom Render Passes, to avoid causing the "IsRichView" function to inadvertently push static meshes into the much slower dynamic code path. The "Lighting" flag has no effect on Custom Render Passes, as they don't run downstream visualization logic, and so is a needless performance cost which is silently introduced if a user touches the flag. Another minor bug noticed and fixed was terrain editing widgets displaying in captures.
#rb tim.doerries, zach.bethel
[CL 34664361 by jason hoerner in ue5-main branch]
Added VF_SUPPORTS_WORLD_POSITION_SHADER_OFFSETS define which can be set to 0 by other VFs if they do not support WPO
[CL 33324686 by dmitriy dyomin in ue5-main branch]
- controlled by r.RayTracing.UseReferenceBasedResidency (disabled by default)
- Gather which FRayTracingGeometry or RayTracingGeometryGroup are referenced by TLAS
- If a RayTracingGeometryGroup is referenced by TLAS, all the LODs are made resident
- doing this requires having an array in FRayTracingGeometryGroup to track which FRayTracingGeometry are part of the group (one per LOD)
- in the future we could track which LODs are actually necessary and only make LODs up to the highest LOD referenced resident.
- Tracking of referenced geometries is only active when cvar is enabled to avoid overhead/allocations when not being used.
#rb Kenzo.Terelst
[CL 33258852 by tiago costa in ue5-main branch]
Add ability for Landscape to disable displacement at a per-cluster granularity past the fade out range.
#rb Brian.Karis
#jira UE-198582
[FYI] rune.stubbe, graham.wihlidal
[CL 33042630 by jamie hayes in ue5-main branch]
- Add "Nanite Pixel Programmable Distance" to static mesh components to allow the disabling of pixel-programmable rasterization for objects at a specified distance from the camera (can be useful to transition from masked to opaque when not noticeable to improve rasterization performance of distant objects).
- Add "Displacement Fade Range" to materials to help the system determine when it can subtly disable displacement for objects in the distance.
- There is still work to be done for disabling pixel programmable and displacement features for VSM. Displacement does not get disabled based on fading range in shadow due to the possibility of artifacts (rendering with no displacement is not the same as rendering at minimum displacement). Pixel programmable distance can also currently cause artifacts in cached VSM shadow for similar reasons (when used with displacement).
#rb Brian.Karis, graham.wihlidal
[FYI] rune.stubbe, andrew.lauritzen, ola.olsson
#jira UE-198582
[CL 32833707 by jamie hayes in ue5-main branch]
Compensates by scaling the FirstLevel VSM depending on the OrthoWidth being used, which has the added benefit of reducing performance for VSM LODs that are not required for Ortho passes. Added a LineTrace system for estimating the location when a ViewTarget is not selected.
Also removes the PostProcess disable setting that previously blocked EyeAdaptation from being applied to Lumen, so SkyLight etc shadows now resolve appropriately, resolving bugs that appear in editor debug views + minimaps.
Also switches Editor debug views to use ortho auto plane calculations/fixes a crash when zooming out. CVars also added for disabling these settings, or forcing different LODBiases in VSMs.
Refactored NearPlane updates to an easier to follow logic path and added compensation for ViewOrigin to ViewTargets.
#jira UE-206860, FORT-604328
#rb Laura.Hermanns, Andrew.Lauritzen
[CL 32322246 by jon cain in ue5-main branch]
Full story : when rendering shadows, we create copies of FViewInfo (via FViewInfo::CreateSnapshot()) which are *not* in the ViewFamily's views of the FSceneRenderer, which prevents the landscape render systems from computing LOD section values. In this case, we want to reuse the originating view's values, which works for views with a view state (as the snapshot view simply copies the origin view's view state) but does not for those without view state.
The fix consists in storing a back pointer to the originating view when creating a snapshot view, so that the landscape render system can fallback to this view's LOD section values when it can't find the view in its cached values
#rb chris.tchou, ola.olsson
[CL 31725792 by jonathan bard in ue5-main branch]
