Save up to 16MB on some platforms.
#rb daniele.vettorel, danny.couture, Kenzo.Terelst
#tests 66d8b4154a47dde1dd226334
#ushell-cherrypick of 36036431 by serge.bernier (first of 2 submits)
[CL 36747837 by serge bernier in 5.5 branch]
#fyi jonathan.bard
Original CL Desc
-----------------------------------------------------------------
Moved landscape visibility layer info asset to from EditorLandscapeResources to EngineResources so that it doesn't get stripped on cook when "Exclude editor content when cooking" is used
#jira UE-224662
#rb luc.eygasier
#virtualized
[CL 36446330 by jonathan bard in 5.5 branch]
Previously it would warn about duplicate landscape GUIDs during cook, because it would load the level with the level instances, but not apply the unique instance GUIDs to each landscape.
This change applies the instance GUID when level instances are loaded in a commandlet, but then restores the original GUID on save.
#rb jonathan.bard
[CL 35806814 by chris tchou in ue5-main branch]
[FYI] jeanfrancois.dube
Original CL Desc
-----------------------------------------------------------------
[Landscape] Fix Landscape proxies registering their landscape info object into the main world instead of their outer world.
The logic behind this changes comes from the fact that WorldCreationEventFunction and WorldDestroyEventFunction uses the outer world to register and unregister landscape info objects.
Also outered landscape info objects to the world they are registered to just to make it clear to what object they belongs to.
#rb Sebastien.Lussier, Jonathan.Bard
#p4v-cherrypick 34932525, 34940115
[CL 35563023 by jeanfrancois dube in ue5-main branch]
The logic behind this changes comes from the fact that WorldCreationEventFunction and WorldDestroyEventFunction uses the outer world to register and unregister landscape info objects.
Also outered landscape info objects to the world they are registered to just to make it clear to what object they belongs to.
#rb Sebastien.Lussier, Jonathan.Bard
#p4v-cherrypick 34932525, 34940115
[CL 35490371 by jeanfrancois dube 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]
This means that the fix requires users to manually rebuild nanite on the affected landscapes, they will not automatically rebuild to correct the issue.
#rb roey.borsteinas
#jira UE-215826, UE-215517
[CL 34131822 by chris tchou in ue5-main branch]
(It was not writing the data to DDC correctly)
Also adding some debug logging
Bumping landscape nanite content ID to force automatic rebuild of the nanite meshes (again)
#rb jonathan.bard
[CL 34106096 by chris tchou in ue5-main branch]
This means that the fix requires users to manually rebuild nanite on the affected landscapes, they will not automatically rebuild to correct the issue.
#rb roey.borsteinas
#jira UE-215826, UE-215517
[CL 34074541 by chris tchou in ue5-main branch]
(the nanite mesh was using proxy relative coords instead of global coords, and was also applying LOD scale incorrectly)
#rb jonathan.bard
#jira UE-215826, UE-215517
[CL 34027288 by chris tchou in ue5-main branch]
Doubly ensure disabled grass generation components never leave the NotReady state in game (and a bit of optimization by completely removing the check in non-editor builds).
#rb jonathan.bard
[CL 34012330 by chris tchou in ue5-main branch]
* Prevent landscape target layers from being renamed to a layer name that's already in use
#jira UE-216036
#rb chris.tchou
[CL 34009471 by jonathan bard in ue5-main branch]
* Another issue was discovered when re-assigning a null target layer of an existing target layer : this would not call Modify on the main landscape actor, which 1) incorrectly prevents the operation from being undone 2) also prevents the actor to be dirty, and therefore, upon reload, the landscape would not retain the proper layer info assignment
* Also fixed a bunch of places where Modify was called before changing landscape properties
#rb chris.tchou
[CL 33948178 by jonathan bard in ue5-main branch]
The textures and materials array must have the same number of entries in serialize and deserialize, and thus cannot depend on whether the pointer is null or not (in fact we replace the property pointers with null on serialize, so it's guaranteed to be null on deserialize, and always have a mismatch in the count)
#rb jonathan.bard
[CL 33794098 by chris tchou in ue5-main branch]
