Note: Added additional change to comment bubble default color based on feedback from design.
#rb aditya.ravichandran, brooke.hubert
#jira UE-213437
#11805
[CL 34164900 by Vesros in ue5-main branch]
With this checkin, the binding system inside Level Sequences has been refactored to allow C++ custom binding classes inheriting from a new class, UMovieSceneCustomBinding. Custom bindings are held as instanced UObjects inside FMovieSceneBindingReference, alongside the Universal Object Locator. In the case where a custom binding has been specified, the UOL will be ignored.
The intention with this change is to allow developers to create their own arbitrary methods of binding any UObject to a track inside Sequencer. Examples of this include:
* Runtime dynamic bindings to spawned NPC or player characters (e.g. in UEFN) with a different spawned preview character
* Blueprint-specified dynamic bindings
* Spawnable bindings based on something other than a AActor template
* Scene Graph/Prefabs
Alongside the base UMovieSceneCustomBinding class, a new hierarchy of spawnable custom binding classes has been created as the basis for allowing spawnable bindings that don't require object templates, and may instead require other asset references, for example UEFN NPC character spawnables requiring an NPC Character Definition asset.
This hierarchy is currently. UMovieSceneCustomBinding <- UMovieSceneSpawnableBindingBase <- UMovieSceneSpawnableActorBindingBase <- UMovieSceneSpawnableActorBinding.
This hierarchy allows for spawnables of non-actor types, spawnables of actor types not based on templates, and finally UMovieSceneSpawnableActorBinding, which is a re-implementation of FMovieSceneSpawnable inside the custom binding system.
Going forward, we will be moving to deprecate FMovieSceneSpawnable in UE Sequencer in favor of the custom spawnable binding types. Sequences with FMovieSceneSpawnables will continue to function as normal, but new spawnables in new sequences will use UMovieSceneSpawnableActorBinding under the hood. These will technically have FMovieScenePossessable structs created for them for now rather than FMovieSceneSpawnable structs. This should be mostly invisible to the user.
In addition, I've added a separate hierarchy of custom bindings called 'Replaceable' bindings. A 'Replaceable' is a binding type that will expect in runtime to always be overridden by a different object that may not be available in editor. UMovieSceneReplaceableBinding will hold in EDITORONLY_DATA a UMovieSceneSpawnableBindingBase to provide a preview while within Sequencer. Included in this is a UMovieSceneReplaceableActorBinding, which uses the UMovieSceneSpawnableActorBinding internally to spawn its preview, and has no implementation to find the actor during runtime- it relies on the user overriding the actor binding using the existing BindingOverrides method on LevelSequenceActor.
Next Steps:
* UEFN custom bindings will be built upon this system, to allow UEFN users multiple ways to override bindings.
* UEFN custom spawnable bindings will be built upon this system, to allow UEFN users a way to spawn actors and objects within Sequencer with their lifetime managed by Sequencer
* With this change, we have a cleaner way of incorporating the 'dynamic binding' work that uses the Director Blueprint to create a spawnable or possessable. This should be incorporated into the UCustomBinding hierarchy.
* Once Verse supports it, we should add Verse custom binding logic
* We need to add a Universal Object Locator type that can reference any other binding in the sequence hierarchy. This will allow us to adapt the existing 'Spawnable Parent' possessable binding logic to reference any other type of binding, not just spawnable ones.
* Eventually we will fully deprecate FMovieSceneSpawnable
Further notes:
* A previous imagined version of this system used the cache as a way to allow locators to spawn actors and register them with Sequencer. This change removes this code.
* Custom Spawnable Bindings use the Binding Lifetime Track to determine their spawn lifetime rather than the old spawn track. This unifies the concept of the lifetime of an object binding within sequencer for both spawnables and possessables.
* As FMovieScenePossessable and FMovieSceneBindingReferences allows multiple bindings per guid, this change now allows multiple spawnables to be spawned and controlled by a single binding track. However, some of the editor tooling code doesn't currently handle this properly and at times assumes a single binding. This should be resolved one way or the other.
* The UX for this allows UCustomBindings to handle creating bindings from any dragged in object using a priority system- Sequencer will ask all classes in priority order if they support binding creation from that object.
* The UX supports unique overlay icons and tooltips for different types of bindings
* The UX allows each binding type to decide whether it can convert a current binding into its own type and then do so
* Currently there is some manual instanced detail customization for UMovieSceneCustomSpawnableActorBinding. We use instanced customization so that the UX has the sequencer context. This should both be improved (to allow ways to choose a class/template via this UI), as well as extended so that clients outside of the Movie Scene plugin can register instanced detail customizations for their own binding types.
* Where possible, Sequencer APIs around spawnables have been refactored to take guids rather than FMovieSceneSpawnable references. In particular, custom spawnables do still use the spawn register, but do not use actor spawners- instead the UMovieSceneCustomBinding class is given the responsiblity of spawning/destroying the object/actor. This created an awkward API for USD export, which had overridden the spawn register to unhide/hide actors rather than spawning/destroying them. This could use some more work. MetaHumanPerformanceExportUtils will also need to be refactored at some point to use the custom spawnable binding system.
* FSequencerUtilities::CreateBinding and CreateGenericBinding has been refactored to accept binding parameters and now supports creating custom bindings including spawnables, as well as replacing existing bindings and adding additional bindings to an existing guid.
[REVIEW] [at]ue-sequencer
#jira UE-199299, FORT-582815, UE-209594
#rb Andrew.Rodham, daniel.coelho, Max.Chen
[CL 32218187 by david bromberg in ue5-main branch]
Changes buttons to toggle buttons for landscape editor BP brushes affecting layers features.
Updates landscape editor target list colors, padding, text color to reflect UE5 style.
#rb Jonathan.Bard
[CL 27346857 by luc eygasier in ue5-main branch]
- Use FScopedActorEditorContextFromActor for operations which need to use the same context as the Source actor
- Update Move Tool to allow Move to current Actor Editor Context. (Allows changing DataLayers / ContentBundle for selected instances)
#rb richard.malo
#rnx
[CL 27315792 by patrick enfedaque in ue5-main branch]
This allows artist to provide a custom LUT describing specular behavior for view and light angles. The LUT can be procedurally generated or provided from a texture.
#rb sebastien.hillaire
#jira none
#preflight 646b6b392c0a5da0dcc8a2ab
[CL 25564387 by Charles deRousiers in ue5-main branch]
New algorithm is in MovieScenCurveChannelImpl where we calculate auto tangents. Since they work off tangents and not key positons, need to make sure to recalc them if the tangent changes now. Since FRichCurve will not support these new auto tangents, they only do 2 key interps with the old auto key algorithm that doesn't average the tangents at all, had to add a SupportedTangentType to FCurveEditor so that we can use that with the curve editor context menu/commands/SCurveEditorPanel since they are all shared between Sequencer and the Curve Asset viewer. Most of the code is making sure we treat smart auto's the same as the old autos
#jira UE-171811
#rb max.chen
#preflight 6446d596dc71c13446fa361a
[CL 25175842 by mike zyracki in ue5-main branch]
#rb graham.wihlidal, brian.karis
#preflight skip
This changelist contains all of the improvements we've made to the texture painting system during our development time.
Here is the full list of included CLs:
1)
"
Improved texture painting debug draw
Before this change, debug draw for the vertex/texture painting tool only displayed vertex colors. This changelist improves the debug draw to show the texture painting data on the mesh proxy in a similar way as the vertex painting.
As part of this changelist, I fix a bug found in FColoredTexturedMaterialRenderProxy::GetParameterValue. The problem was that the FColoredTexturedMaterialRenderProxy overrides a color and a texture parameter, but we only considered the texture parameter. This was preventing the texture painting to display different color channels on request.
Full list of changes:
Added directory of new special material, TexturePaintingMaskMaterial, to BaseEngine.ini
Updated Engine.h/UnrealEngine.cpp to keep a texture painting mask material. (TexturePaintingMaskMaterial.uasset). This material splits has a color parameter and a texture parameter. The texture parameter is filtered based on the color parameter for RBG channels. When all channels (RBG) are set to 0, we display the alpha as the color purple instead of opacity because alpha is typically used as a texture mask in the use cases for texture painting.
Updated FColoredTexturedMaterialRenderProxy::GetParameterValue to call base class functions in order to correctly query the color parameter.
Added the transient weak object pointer "OverridePaintTexture" to "UMeshPaintingSubsystem". This is set by the texture painting system to override the texture painting debug draw during active drawing.
Added the weak object pointer global "GVertexViewModeOverrideTexture" which is used to propagate debug draw behavior to relevant meshes that are being painted. This follows the method already in place for the vertex color debug draw.
Updated StaticMeshRender.cpp/SkeletalMesh.cpp to now handle the new "GVertexViewModeOverrideTexture" weak object pointer.
Added the enum class "EMeshPaintActiveMode" which is used by the paint mode subsystem when setting the viewport color mode. This is used to differentiate when to show debug draw for normal color, weights, and texture. The names chosen here follow the same names as the tools themselves.
"
2)
"
Support for Texture Painting Flood Fill tool
This changelist adds the feature for a "Flood Fill" tool option for Texture painting.
To use the new feature:
1) Change to Mesh Paint Mode using the gamemode drop-down in the top right corner of the editor.
2) Change to the "Textures" tab in the Mesh Paint window.
3) Click on the new "Paint Bucket" button near the paint button on the texture painting tool to fill the texture using the current options.
The flood fill tool takes into consideration the UV channel, brush texture, alpha channel, and all color channels on the option configuration. This is accomplished by using the same texture painting shader passes as normal painting. The difference is there is now a new permutation for the paint bucket fill which no longer limits the draw to just the selected area.
Full list of changes:
Added the boolean "bUseFillBucket" to FMeshPaintParameters to pass forward whether or not we are using the fill bucket tool.
Updated "UMeshPaintMode::BindCommands" with a new action for the paint bucket "TextureFill".
Updated UMeshPaintMode with a new function "FillWithTextureColor" which is bound to the paint mode command "TextureFill".
Updated "MeshPaintPixelShader.usf" with the shader permutation macro for "MESH_PAINT_USE_FILL_BUCKET" which will output a simple flood if no paint brush is selected. If a paint brush is selected, it will fill the texture using the brush texture which respects an input rotation.
Added permutation FMeshPaintUseFillBucket to "TMeshPaintVertexShader".
Added logic in "UMeshTexturePaintingTool::OnTick" to handle paint bucket requests.
"
3)
"
Fixes for Mesh Painting Texture Filter, Infinite Loop
This change resolves two mesh painting UI bugs.
The first issue was the Paint Texture filter always returning no results, resulting in only the first texture in the list being paintable. This was due to the filtering function using a generic editor asset name instead of the candidate texture's full name when comparing against the list of valid paintable textures. This change resolves this issue by using the full name from the asset's associated UTexture2D instead.
The second issue was an infinite loop that freezes the editor UI. This would occur when opening the texture painting options for a mesh with a non-instance material associated to it. This change resolves this issue by adding the appropriate break condition to handle this case.
"
4)
"
Fixed Material Texture Parameter Override not refreshing
Before this change, the texture painting system would not properly show active textures being drawn on layered materials. This was because "UMaterialInstance::OverrideTextureParameterValue" only overrode the surface level material and did not consider parent materials.
To fix this, I have now updated "UMaterialInstance::OverrideTextureParameterValue" to also call this function on any existing parents. Along with this, "UMaterialInstance::ResetAllTextureParameterOverrides" is now recursive on its parent for proper texture parameter override cleanup.
As part of this change, I have now also updated IMeshPaintComponentAdapter::DefaultQueryPaintableTextures to query parent material instances for suitable textures for painting. This is needed because parent paintable textures were not being shown in the texture painting tool.
"
5)
"
Fixing a mesh painting bug due to the source texture not being checked for validity. This happens on a "Default_RenderTarget_Clear" texture that has no source texture.
"
6)
"
Texture Painting - Improved material parameter visiblity
Before this change, the texture painting tool only considered textures visible on the top level of a material script. This meant artists needed to to purposely expose any textures needed for painting outside of any material functions in order to paint the texture using the tool. This changelist fixes this problem by now iterating on a given material's texture parameters when filtering out paintable textures.
Full list of changes:
Added helper function "IsTextureSuitableForTexturePainting" in "IMeshPaintComponentAdapter.cpp" to avoid code duplication.
Updated "IMeshPaintComponentAdapter::DefaultQueryPaintableTextures" to iterate through texture parameter values.
Removed the local boolean "bIsTextureUsed" from "UMeshTexturePaintingTool::StartPaintingTexture". This is because "IMeshPaintComponentAdapter::DefaultQueryPaintableTextures" already filters out any unused textures, so filtering again here is unnecessary.
This change was needed in this CL because "UTexturePaintToolset::DoesMeshComponentUseTexture" does not consider texture parameters. I opted to completely remove "bIsTextureUsed" instead of updating the function. This is to prevent any future bugs relating to "DoesMeshComponentUseTexture" not matching "DefaultQueryPaintableTextures".
"
7)
"
Improved texture painting undo/redo stability
Before this change, a 2 crashes could occur when rapidly hitting the undo/redo key when using the texture painting tool. This changelist fixes both crashes.
The first crash would happen due to the internal bulk data being invalid. This can happen when texture streaming is cancelled mid-stream and a new texture 2D is assigned. To fix this, I now use the "Texture2D::Modify" function to refresh the bulk data if needed and wait for any streaming before doing any painting.
The second crash would happen if undo/redo was triggered while the user is currently painting. This is because the function "UMeshTexturePaintingTool::StartPaintingTexture" would assume that the current texture is streamed in if "bStartedPainting" is true. However, this isn't the case if the user "undos" a painting operation while holding down the paint button. To fix this, I now condition both "bStartedPainting" and "bIsSourceTextureStreamedIn" when attempting to continue a painting operation.
"
8)
"
Fixing a Texture Painting crash that occurs when editor is using SM6
"
9)
"
Feature Support for Texture Painting Brushes
Before this changelist, it was only possible to use the texture painting tool to paint a single color using a solid brush. This changelist adds support for custom texture painting brushes on the texture painting tool.
To use the new feature:
1) Change to Mesh Paint Mode using the gamemode drop-down in the top right corner of the editor.
2) Change to the "Textures" tab in the Mesh Paint window.
3) Use the "Paint Brush" parameter to select from any texture in-editor as a brush.
4) Use the "Paint Brush Rotation Offset" parameter to set the initial 2D rotation of the texture on a mesh.
5) Optionally select "Rotate Brush Towards Direction" to continously paint a texture in a given direction on a mesh.
6) Paint onto any surface
Full list of changes:
Added the variable "BrushPosition2D" to FMeshPaintParameters which is now used for tracking our current and previous 2D brush position.
Added the variable "PaintBrushRenderTargetTexture" to "FPaintTexture2DData" to hold a local copy of any texture brush being used for painting.
Updated "MeshPaintPixelShader.usf" with seperate painting paths for applying a paint brush texture.
Updated "TMeshPaintPixelShader" to now bind and pass in the new paint brush parameters.
Updated "TMeshPaintPixelShader" with two new permutation domains (FMeshPaintUsePaintBrush and FMeshPaintUseRotateTowardDirection).
Fixed a small bug in SetMeshPaintShaders where the normal mesh paint pass was using the GMeshPaintDilateVertexDeclaration instead of the GMeshPaintVertexDeclaration declaration. I have opted to correct this in this changelist since I was already editing this area of code with the new permutation vectors.
Updated "FMeshPaintShaderParameters" with the new paint brush related parameters.
Updated "UMeshTexturePaintingToolProperties" with the new paint brush related parameters.
Added optional parameter to "UMeshTexturePaintingTool::PaintTexture" to pass in last attempt's parameters which is used for calculating our 2D movement vector for the "Rotate Brush towards direction" feature.
Updated "UMeshTexturePaintingTool" to now keep track of LastPaintRayResults to use when determining the 2D movement vector.
Potential improvements:
Update the dilate texture painting to also support the texture painting brushes. Currently, it doesn't seem that artists are using the dilate feature, so this changelist only targets the normal texture painting.
Add support for triplanar mapping.
"
10)
"
Updated Active Texture Painting Selection
This changelist is a quality of life improvement for texture painting to always have paintable texture selected if one is available.
Before this change, it was possible to have no paint texture selected even if we have available options. This ended up causing confusion when debug draw was enabled. In this case, the debug draw would show no texture painting information because the draw shows only the currently active paintable texture.
This changelist fixes that by now recaching the paint texture in the function "UMeshTexturePaintingTool::OnTick" when a paintable texture is available but the texture properties has the active texture set to nullptr.
"
11)
"
Default UV Channel to light map coordinate index
Before this change, the default value for UV Channel was always 0 which doesn't always align with what the user would like to paint. This caused confusion when trying to paint, but the channel was incorrect. This change updates the constructor for UMeshTexturePaintingToolProperties to now set the default UVChannel value to the light map coordinate index of the first selected mesh. It is still possible to change the UVChannel manually, but this index is likely the one users would be wanting to paint when using the mesh painting tool.
"
12)
"
Fixed texture parameters not taken for consideration for texture painting
Before this change, it was not possible to texture paint a material's texture if that texure was registered as a texture parameter. This was clearly not intentional because the texture painting tool gathers texture parameters as paintable textures in the function "IMeshPaintGeometryAdapter::DefaultQueryPaintableTextures". The reason why texture parameters weren't being painted is because the "UMaterialInterface::OverrideTexture" editor only function did not consider texture parameters when assigning an override texture. This meant that the painted texture would never override the texture parameter actually being used for render.
To fix this, I have now updated the "OverrideTexture" method to also override any appropiate texture parameters. I believe this is an overlooked edge case of the override texture functionality, so it is necessary to modify the function here instead of creating a workaround in the texture painting system. My implementation in this changelist stores an array of "texture parameter overrides" which is a custom struct with an object pointer to the old texture and the new one, and then on setting new textures, we reference this array. This is editor-only.
With these changes, I have tested the texture painting tool on materials with and without texture parameters along with the following scenarios:
saving/loading texture painted materials in-progress and committed/saved.
undo/redo
copy/paste
destroy/creation
moving/edit transform
All cases tested worked as expected.
Detailed changes:
Updated UMaterialInstance::GetTextureExpressionValues to consider the override textures. This function is used to collect all textures used by a given material instance.
Updated UMaterialInstance::OverrideTexture to now also override the texture parameter value.
Updated UMaterialInstance::Serialize to reset all texture parameter overrides on serialize to avoid serializing any in-progress texture parameters.
Updated UMaterialInstance::ClearParameterValuesInternal to reset the texture parameter overrides if we are resetting the normal texture parameters.
Created the new function "UMaterialInstance::OverrideTextureParameterValue", which is used to manage any registered overridden textures in editor. Requesting an override texture with "nullptr" will remove a given entry from the overrides. This function is meant to work the same way on the texture parameters as "UMaterialInstance::OverrideTexture" does on the internal texture transient overrides.
Created the new helper function "UMaterialInstance::ResetAllTextureParameterOverrides" which iterates through all of our overrides and properly removes them.
Made the function "UMaterialInterface::GetTextureParameterValue" virtual and created the function "UMaterialInstance::GetTextureParameterValue" which overrides any relevant texture parameter value using the internal transient texture parameter overide array. Outside of editor, the function will end up only calling the base function.
Updated "UMeshTexturePaintingTool::OnTick" to clear all texture overrides when a recache is necessary. This fixes a problem where "undo" wasn't reflecting in the texture at times because a stal texture override was being used. By clearing at this spot, any necessary texture overrides will be registered later.
"
13:
"
Fix Texture Painting Visualization
The visualization for texture painting was not showing before this change. The issue is that ShouldProxyUseVertexColorVisualization was returning false when it shouldn't be. GVertexViewModeOverrideOwnerName seems to be an empty string when it should still be the currently painted component name. The string is being set in UMeshTexturePaintingTool::CanBeginClickDragSequence but is then being immediately reset by a call to UMeshTexturePaintingTool::ClearAllTextureOverrides. To fix this I also set GVertexViewModeOverrideOwnerName in the function UMeshPaintModeSubsystem::SetViewportColorMode. This function gets called every frame and will re-register the name string after being cleared. It is also where another override variable, GVertexViewModeOverrideTexture, is already being re-registered.
"
#ushell-cherrypick of 24639501 by Jess.Kube
[CL 24667907 by graham wihlidal in ue5-main branch]
* Deprecate Render method for BP Brushes, RenderLayer should now be used
* Adds FLandscapeBrushParameters struct that should be used to pass arguments when rendering a layer
* Modifies ELandscapeToolTargetType to be an enum class, usable by blueprints
* Adds BP Brush visibility layer toggle in Landscape Editor
* Adds visibility layer editing for LandscapeCircleHeightPatches
* Adds visibility layer editing for LandscapeTexturePatches
* Adds helper method to determine if a layer info object name is a visibility layer
#jira UE-163386
#rb Jonathan.Bard
#preflight 63ebb119e92f139c51b2a842
[CL 24251734 by luc eygasier in ue5-main branch]
It was the initial bug, but while looking at it, I noticed that the MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.
In order to fix the underlying issue (in addition to fix the initial bug), I removed the Font from FEditableTextBoxStyle, and moved the FTextBlockStyle from MultilineEditableTextBox to FEditableTextBoxStyle.
It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the text block style is now embedded in the editable text box style, it cannot be initialized the exact same way, and I had to do some changes to ensure there was no regression, by configuring various FEditableTextBoxStyle in some style files. I also change the default value for TextBlockStyle to better match our default theme.
-Default font is not set for text widgets.
EditableWidget: ensure to have a default font, and to set the style when calling SynchronizeProperties to ensure it reacts directly without having to force a refresh (by moving the widget for instance)
Bonus:
-Move to cpp some private methods that where 'forced' inline (and we were using function pointer on them). It will avoid some noise in public interface and speed up iteration / compile time when playing with them.
#jira UE-96464
#jira UE-137126
[RN] MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.The Font from FEditableTextBoxStyle has been removed, and the FTextBlockStyle moved from MultilineEditableTextBox to FEditableTextBoxStyle. It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the FTextBlockStyle is now embedded in the FEditableTextBoxStyle, it cannot be initialized the exact same way, and you can now configure the FTextBlockStyle of FEditableTextBoxStyle when creating one from scratch, by calling SetTextStyle on it.
Test
- created a Widget blueprint with different editable types combination: multiline or single line, box or no box.
-Validated that everything was reacting live as expected now.
-Created a blue print to set the text style and validated it was working.
-Create data with old version, then open it with updated version to validate that the visual was still the same and deprecation of style working as expected.
-checked different places in the editor using variation of editable text to ensure they were behaving as before (detail view, console command entry, comment on blueprint node).
#preflight 63344b9f110bb3721ef8aa77
[CL 22232366 by yohann dossantos in ue5-main branch]
- Refactored viewport's current level combobox and added "current data layers" in data layer outliner and "current folder" in world outliner to use this system.
- Can optionally be hidden from viewport using advanced flag in ULevelEditorViewportSettings.
#robomerge FNNC
#rb patrick.enfedaque
#preflight 6227604a7077eb04cf696c33
[CL 19302351 by Richard Malo in ue5-main branch]
- Added ability to toggle Private Content Edit mode at Folder level in Content Browser
- You cannot edit an asset's Private/Public state unless it's within a Private Content Editable folder
- Private Assets do not show up unless their within a Private Content Editable folder
#preflight 621fbc63e15c51d8c509559d
#rb Rex.Hill
#ROBOMERGE-OWNER: rex.hill
#ROBOMERGE-AUTHOR: scott.nelson
#ROBOMERGE-SOURCE: CL 19226371 via CL 19235626 via CL 19238850 via CL 19238931 via CL 19245779
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v924-19243027)
[CL 19247024 by rex hill in ue5-main branch]
