#rb Steve.Robb
#jira UE-221511
[RN] UStructs above 16.7mb will trip an ensure in the Editor so that they remain compatible with upcoming changes to Max ElementSize. You can disable the ensure with CVar CoreUObject.EnsureAgainstLargeProperties.
[CL 35434186 by jodon karlik in ue5-main branch]
[FYI] Yoan.StAmant
Original CL Desc
-----------------------------------------------------------------
Moved UserDefinedStruct to CoreUObject
#jira UE-216472
#rb Devin.Doucette
[CL 34486763 by gary yuan in ue5-main branch]
- Added property functions which can be executed and chained during property binding to set values of properties
[CL 34087989 by mikko mononen in ue5-main branch]
[FYI] mikko.mononen
Original CL Desc
-----------------------------------------------------------------
StateTree: Introduced PropertyFunctions (contributed)
- Added property functions which can be executed and chained during property binding to set values of properties
[CL 33868630 by justin peterson in ue5-main branch]
- Added property functions which can be executed and chained during property binding to set values of properties
[CL 33856515 by mikko mononen in ue5-main branch]
- Added editor only StatePath to FStateTreeBindableStructDesc to help error reporting
- Friendlify user defined struct property names in FStateTreePropertyPath::ToString()
- Fixed FStateTreeEditorNode::GetName() to return the BP node name instead of the wrapper name
- Categorize binding sources based on state (including one section for global) in the binding popup
#jira UE-212418, UE-209016
#rb Yoan.StAmant
[CL 33623462 by mikko mononen in ue5-main branch]
[FYI] marshall.beachy
Original CL Desc
-----------------------------------------------------------------
Performance improvement for nested FInstancedStruct in details panel
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33319481 by logan buchy in ue5-main branch]
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33242716 by logan buchy in ue5-main branch]
[Backout] - CL33171468
[FYI] logan.buchy
Original CL Desc
-----------------------------------------------------------------
Performance improvement for nested FInstancedStruct in details panel
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33205050 by robert millar in ue5-main branch]
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33171500 by logan buchy in ue5-main branch]
[FYI] logan.buchy
Original CL Desc
-----------------------------------------------------------------
Performance improvement for nested FInstancedStruct in details panel
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33161624 by logan buchy in ue5-main branch]
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33154559 by logan buchy in ue5-main branch]
- Added FStateTreePropertyRef which allows to get pointer to bindable output properties in the StateTree
- This will eventually supercede FStateTreeStructRef
[CL 30563615 by mikko mononen in ue5-main branch]
- Allow each state to have parameters (not super useful yet)
- Made property bindings for parameters to retain binding when a param is renamed (keeps track of the property bag ID)
- Fixed access of temporary instance data with EStateTreeDataSourceType::StateParameterData
- Added comments for UStateTreeState properties
- Changed property order of UStateTreeState so that display data comes first, then state settings, and finally parameters
- Fixed FStateTreeStateParametersInstanceDataDetails to allow property editing and value binding at the same time
#rb Mieszko.Zielinski
[CL 30112368 by mikko mononen in ue5-main branch]
- Remove DataView concept
- Added FStateTreeExecutionFrame, which defines an active branch of a specific state tree that is running
- Added FStateTreeDataHandle, which allows frame relative access of instance data (replaces the DataViews)
- Changed linked states to spawn new frames (will later extend to handle linked trees on other assets)
- Bumped StateTree data version number, requires recomplation of StateTrees
#rb Yoan.StAmant
[CL 29884503 by mikko mononen in ue5-main branch]
[FYI] mikko.mononen
Original CL Desc
-----------------------------------------------------------------
StateTree: Changed how instance data is accessed
- Remove DataView concept
- Added FStateTreeExecutionFrame, which defines an active branch of a specific state tree that is running
- Added FStateTreeDataHandle, which allows frame relative access of instance data (replaces the DataViews)
- Changed linked states to spawn new frames (will later extend to handle linked trees on other assets)
- Bumped StateTree data version number, requires recomplation of StateTrees
#rb Yoan.StAmant
[CL 29810071 by grant medine in ue5-main branch]
