Navigation
API > API/Runtime > API/Runtime/Landscape > API/Runtime/Landscape/ALandscapeBlueprintBrushBase
Overloads
| Name | Remarks | Include Path | Unreal Specifiers |
|---|---|---|---|
UTextureRenderTarget2D * RenderLayer
(
const FLandscapeBrushParameters& InParameters |
LandscapeBlueprintBrushBase.h |
|
|
virtual bool RenderLayer
(
UE::Landscape::EditLayers::FRenderParams& RenderParams, |
RenderLayer is where the renderer has a chance to render its content and eventually blend it with the merged result of all preceding layers (if ERenderFlags::BlendMode_SeparateBlend is not returned) It operates on a limited set of components (depending on the size of the render batches) and on a set of target layers (e.g. multiple weightmaps). | LandscapeBlueprintBrushBase.h |
RenderLayer(const FLandscapeBrushParameters &)
| Name | RenderLayer |
| Type | function |
| Header File | /Engine/Source/Runtime/Landscape/Public/LandscapeBlueprintBrushBase.h |
| Include Path | #include "LandscapeBlueprintBrushBase.h" |
UFUNCTION (BlueprintNativeEvent)
UTextureRenderTarget2D * RenderLayer
(
const FLandscapeBrushParameters & InParameters
)
RenderLayer(UE::Landscape::EditLayers::FRenderParams &, UE::Landscape::FRDGBuilderRecorder &)
Description
RenderLayer is where the renderer has a chance to render its content and eventually blend it with the merged result of all preceding layers (if ERenderFlags::BlendMode_SeparateBlend is not returned) It operates on a limited set of components (depending on the size of the render batches) and on a set of target layers (e.g. multiple weightmaps). It guarantees access to the merged result from preceding layers of each target layer.
| Name | RenderLayer |
| Type | function |
| Header File | /Engine/Source/Runtime/Landscape/Public/LandscapeBlueprintBrushBase.h |
| Include Path | #include "LandscapeBlueprintBrushBase.h" |
| Source | /Engine/Source/Runtime/Landscape/Private/LandscapeBlueprintBrushBase.cpp |
virtual bool RenderLayer
(
UE::Landscape::EditLayers::FRenderParams & RenderParams,
UE::Landscape::FRDGBuilderRecorder & RDGBuilderRecorder
)
true if anything was rendered
Parameters
| Name | Remarks |
|---|---|
| RenderParams | contains parameters necessary for this render (affected components, merge context, etc.) |
| RDGBuilderRecorder | recorder to append operations to a single FRDGBuilder, if the the recorder in "recording" mode. In "immediate" mode, a render command will be enqueued immediately. The recorder can be in 2 states, depending on the result from GetRenderFlagsERenderFlags::RenderMode_Immediate : the recorder is in immediate mode renderer can enqueue render commands just like any other game thread-based rendererERenderFlags::RenderMode_Recorded : the function runs on the game thread but is not meant to enqueue render commands directly. Instead, it registers consecutive "render commands" via "RDG/render command" accumulated on a FRDGBuilderRecorder. This allows to coalesce several render commands onto the same FRDGBuilder (which is critical for performance) while still allowing to interleave game thread-based renders (flushing the command recorder, enqueuing the game thread-based render, and starting recording on the same (or a new) command recorder again...) TLDR: when using the ERenderFlags::RenderMode_Recorded method, the user should use the command recorder to enqueue lambdas instead if enqueuing render commands directly. Corollary: Any render command issued by RenderLayer will end up being pushed before the render operations recorded on the RDG command recorder (unless it is flushed), so there's no reason to actually do it, unless you want those commands to run before the recorded commands |