* The new merge algorithm also speeds up the merging process by performing the merge operation in a single shader pass, which avoids intermediate clear/copies, even more so when dealing with several edit layers (O(n) -> O(1))
* Implemented via FRDGBuilder to benefit from transient memory allocation and optimal resource transitions.
* This is activated by a CVar (landscape.EditLayersLocalMerge.Enable, disabled by default) and disabled for landscapes containing BP brushes, since customers (similar to what the WaterBrushManager did) might have made the assumption that the merge is global and we don't want to break the existing landscapes.
For heightmaps:
* The algorithm is divided into several "component resolve batches" that render a list of neighboring components and merge all their edit layers into a single slice of a scratch texture array (first, copy all the edit layers texture subregions to a texture array then merge them in a single shader pass). Then those rendered components' borders are stitched (in order to mimic the behavior of global merge) so that there are no seams in between components even if they were not properly authored (i.e. one component authored while its neighbor was not loaded). Then normals are generated in another pass.
* In order to limit the amount of temporary copies of heightmaps, batches only render a max number of landscape components (including neighbor components), controlled by CVar landscape.EditLayersLocalMerge.MaxComponentsPerHeightmapResolveBatch. This means that a given component can effectively be rendered (i.e. merged) multiple times if it's needed for the computation of different batches but batches are built in a way to minimize this situation.
* Finally, mips are generated and the resulting heightmaps are copied to staging textures the same way they used to.
For weightmaps:
* The algorithm is divided into several "weightmap resolve batches" that render a list of components that participate to the output of a list of given weightmaps, processing each individual channel into a single slice of a scratch texture array (first, copy all the edit layers texture channels to a texture array then merge them in a single shader pass). Then, the weightmaps to resolve within the batch are finalized (i.e. individual, single-channel, weightmaps are packed into the final multi-channel weightmap), their mips are generated and the resulting weightmaps are copied to staging textures the same way they used to.
* In order to limit the amount of temporary copies of weightmaps, batches only render a max number of individual weightmaps, controlled by CVar landscape.EditLayersLocalMerge.MaxComponentsPerWeightmapResolveBatch. This means that a given weightmap can effectively be rendered (i.e. merged) multiple times if it's needed for the computation of different batches but batches are built in a way to minimize this situation.
Misc:
* Fixed RHI validation for GlobalMerge of weightmaps
* Moved landscape render resources to their own file to de-clutter LandscapeEditLayers.cpp a bit
* landscape.RenderCaptureLayersNextHeightmapDraws and landscape.RenderCaptureLayersNextWeightmapDraws now support capturing several draw calls
* Moved all intermediate containers (LandscapeComponentHeightmapsToRender/ToResolve, MapHelper, etc.) to a context object in order to centralize the local/global merge common structures. Note : the context is mutable and can be partially refreshed since weightmaps can be potentially added by the merge algorithms and therefore those structures were not up to date and we could miss reading back from newly-added weightmap textures
* Removed unused WeightmapLayersBlendSubstractive in global merge algorithm
* CVar commands landscape.Dirty and landscape.FixSplines now process all loaded game worlds
The next step is to re-work our internal brushes and provide a new API for them and user-implemented ones to work in the same fashion. Then the old BP brush API will be progressively phased out.
#rb sebastien.lussier, patrick.enfedaque
#tests full QA pass (UEENGQA-60460)
#preflight 61d8bc681f62d3ad4d728095
#ROBOMERGE-AUTHOR: jonathan.bard
#ROBOMERGE-SOURCE: CL 18751747 via CL 18751748 via CL 18751754 via CL 18751906 via CL 18751983
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v903-18687472)
[CL 18751988 by jonathan bard in ue5-main branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
#rb johan.torp
GetLinkerUE4Version renamed to GetLinkerUEVersion
#ROBOMERGE-SOURCE: CL 15859222 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15859586 by mark lintott in ue5-main branch]
- Non WP worlds still use the ALandscapeProxy as a ULandscapeSplinesComponent container
- WP worlds create one ALandscapeSplineActor per Spline that have their own bounds (so they can be loaded properly based on that)
#rb richard.malo, sebastien.lussier
[CL 14806261 by Patrick Enfedaque in ue5-main branch]
