Files
UnrealEngineUWP/Engine/Source/Runtime/MeshDescription/Public/MeshElementArray.h

314 lines
9.5 KiB
C
Raw Normal View History

// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "CoreMinimal.h"
/**
* This defines the container used to hold mesh elements.
* Its important properties are that it acts as an associative container (i.e. an element can be obtained from
* a given index), and that insert/delete/find are cheap.
* The current implementation is as a TSparseArray, but we abstract it so that this can be changed later if
* required, e.g. a TMap might be desirable if we wished to maintain unique indices for the lifetime of the container.
*/
template <typename ElementType>
class TMeshElementArrayBase
{
public:
/**
* Custom serialization for TMeshElementArrayBase.
* The default TSparseArray serialization also compacts all the elements, removing the gaps and changing the indices.
* The indices are significant in editable meshes, hence this is a custom serializer which preserves them.
*/
friend FArchive& operator<<( FArchive& Ar, TMeshElementArrayBase& Array )
{
Array.Container.CountBytes( Ar );
if( Ar.IsLoading() )
{
// Load array
TBitArray<> AllocatedIndices;
Ar << AllocatedIndices;
Array.Container.Empty( AllocatedIndices.Num() );
for( auto It = TConstSetBitIterator<>( AllocatedIndices ); It; ++It )
{
Array.Container.Insert( It.GetIndex(), ElementType() );
Ar << Array.Container[ It.GetIndex() ];
}
}
else
{
// Save array
const int32 MaxIndex = Array.Container.GetMaxIndex();
// We have to build the TBitArray representing allocated indices by hand, as we don't have access to it from outside TSparseArray.
// @todo core: consider replacing TSparseArray serialization with this format.
TBitArray<> AllocatedIndices( false, MaxIndex );
int32 MaxAllocatedIndex = 0;
for( int32 Index = 0; Index < MaxIndex; ++Index )
{
if( Array.Container.IsAllocated( Index ) )
{
AllocatedIndices[ Index ] = true;
MaxAllocatedIndex = Index;
}
}
// Cut off the trailing unallocated indices so that they are not serialized
AllocatedIndices.SetNumUninitialized(MaxAllocatedIndex + 1);
Ar << AllocatedIndices;
for( auto It = Array.Container.CreateIterator(); It; ++It )
{
Ar << *It;
}
}
return Ar;
}
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
/** Compacts elements and returns a remapping table */
void Compact( TSparseArray<int32>& OutIndexRemap );
/** Remaps elements according to the passed remapping table */
void Remap( const TSparseArray<int32>& IndexRemap );
protected:
/** The actual container, represented by a sparse array */
TSparseArray<ElementType> Container;
};
/**
* We prefer to access elements of the container via strongly-typed IDs.
* This derived class imposes this type safety.
*/
template <typename ElementType, typename ElementIDType>
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
class TMeshElementArray final : public TMeshElementArrayBase<ElementType>
{
static_assert( TIsDerivedFrom<ElementIDType, FElementID>::IsDerived, "ElementIDType must be derived from FElementID" );
using TMeshElementArrayBase<ElementType>::Container;
public:
/** Resets the container, optionally reserving space for elements to be added */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE void Reset( const int32 Elements = 0 )
{
Container.Reset();
Container.Reserve( Elements );
}
/** Reserves space for the specified total number of elements */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE void Reserve( const int32 Elements ) { Container.Reserve( Elements ); }
/** Add a new element at the next available index, and return the new ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementIDType Add() { return ElementIDType( Container.Add( ElementType() ) ); }
/** Add the provided element at the next available index, and return the new ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementIDType Add( typename TTypeTraits<ElementType>::ConstInitType Element ) { return ElementIDType( Container.Add( Element ) ); }
/** Add the provided element at the next available index, and return the ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementIDType Add( ElementType&& Element ) { return ElementIDType( Container.Add( Forward<ElementType>( Element ) ) ); }
/** Inserts a new element with the given ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementType& Insert( const ElementIDType ID )
{
Container.Insert( ID.GetValue(), ElementType() );
return Container[ ID.GetValue() ];
}
/** Inserts the provided element with the given ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementType& Insert( const ElementIDType ID, typename TTypeTraits<ElementType>::ConstInitType Element )
{
Container.Insert( ID.GetValue(), Element );
return Container[ ID.GetValue() ];
}
/** Inserts the provided element with the given ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementType& Insert( const ElementIDType ID, ElementType&& Element )
{
Container.Insert( ID.GetValue(), Forward<ElementType>( Element ) );
return Container[ ID.GetValue() ];
}
/** Removes the element with the given ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE void Remove( const ElementIDType ID )
{
checkSlow( Container.IsAllocated( ID.GetValue() ) );
Container.RemoveAt( ID.GetValue() );
}
/** Returns the element with the given ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementType& operator[]( const ElementIDType ID )
{
checkSlow( Container.IsAllocated( ID.GetValue() ) );
return Container[ ID.GetValue() ];
}
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE const ElementType& operator[]( const ElementIDType ID ) const
{
checkSlow( Container.IsAllocated( ID.GetValue() ) );
return Container[ ID.GetValue() ];
}
/** Returns the number of elements in the container */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE int32 Num() const { return Container.Num(); }
/** Returns the index after the last valid element */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE int32 GetArraySize() const { return Container.GetMaxIndex(); }
/** Returns the first valid ID */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementIDType GetFirstValidID() const
{
return Container.Num() > 0 ?
ElementIDType( typename TSparseArray<ElementType>::TConstIterator( Container ).GetIndex() ) :
First pass of MeshDescription API and format refactor. - Removed hardcoded element type arrays (Vertices, Edges, Triangles etc.). Mesh element types can now be arbitrarily added, with any number of channels. - Mesh element containers have a much leaner format; instead of sparse arrays, they are now represented by a simple bitarray, determining whether an index is used or not. Consequently, mesh topology is now entirely described with the attribute system, e.g. edge start and end vertices, triangle vertices, etc. - Support added for attributes of arbitrary dimensions, e.g. float[4] or int[2]. - Support added for attributes which index into another mesh element container. - Added FMeshElementIndexer: this is an efficient container for maintaining backward references from one element type to another; for example, edges have an attribute specifying which vertices are at each end (an attribute of type FVertexID[2]). With an indexer, it is possible to look up which edges contain a given vertex, even though this is not explicitly stored. Indexers are designed to do minimal allocations and update lazily and in batch when necessary. - Added support for preserving UV topology in static meshes. UVs are now a first-class element type which may be indexed directly from triangles. - Added the facility to access the underlying array in an attribute array directly. - Triangles now directly reference their vertex, edge and UV IDs. Vertex instances are to be deprecated. - Changed various systems to be triangle-centric rather than polygon-centric, as this is faster. Triangles are presumed to be the elementary face type in a MeshDescription, even if polygons are still supported. The concept of polygons will be somewhat shifted to mean a group of triangles which should be treated collectively for editing purposes. - Optimised normal/tangent generation and FBX import. - Deprecated EditableMesh, MeshEditor and StaticMeshEditorExtension plugins - these are to be removed, but they still have certain hooks in place which need removing. #rb [CL 13568702 by Richard TalbotWatkin in ue5-main branch]
2020-05-28 10:56:57 -04:00
INDEX_NONE;
}
/** Returns whether the given ID is valid or not */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE bool IsValid( const ElementIDType ID ) const
{
return ID.GetValue() >= 0 && ID.GetValue() < Container.GetMaxIndex() && Container.IsAllocated( ID.GetValue() );
}
/** Serializer */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE friend FArchive& operator<<( FArchive& Ar, TMeshElementArray& Array )
{
Ar << static_cast<TMeshElementArrayBase<ElementType>&>( Array );
return Ar;
}
/**
* This is a special type of iterator which returns successive IDs of valid elements, rather than
* the elements themselves.
* It is designed to be used with a range-for:
*
* for( const FVertexID VertexID : GetVertices().GetElementIDs() )
* {
* DoSomethingWith( VertexID );
* }
*/
class TElementIDs
{
public:
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
explicit FORCEINLINE TElementIDs( const TSparseArray<ElementType>& InArray )
: Array( InArray )
{}
class TConstIterator
{
public:
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
explicit FORCEINLINE TConstIterator( typename TSparseArray<ElementType>::TConstIterator&& It )
: Iterator( MoveTemp( It ) )
{}
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE TConstIterator& operator++()
{
++Iterator;
return *this;
}
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE ElementIDType operator*() const
{
First pass of MeshDescription API and format refactor. - Removed hardcoded element type arrays (Vertices, Edges, Triangles etc.). Mesh element types can now be arbitrarily added, with any number of channels. - Mesh element containers have a much leaner format; instead of sparse arrays, they are now represented by a simple bitarray, determining whether an index is used or not. Consequently, mesh topology is now entirely described with the attribute system, e.g. edge start and end vertices, triangle vertices, etc. - Support added for attributes of arbitrary dimensions, e.g. float[4] or int[2]. - Support added for attributes which index into another mesh element container. - Added FMeshElementIndexer: this is an efficient container for maintaining backward references from one element type to another; for example, edges have an attribute specifying which vertices are at each end (an attribute of type FVertexID[2]). With an indexer, it is possible to look up which edges contain a given vertex, even though this is not explicitly stored. Indexers are designed to do minimal allocations and update lazily and in batch when necessary. - Added support for preserving UV topology in static meshes. UVs are now a first-class element type which may be indexed directly from triangles. - Added the facility to access the underlying array in an attribute array directly. - Triangles now directly reference their vertex, edge and UV IDs. Vertex instances are to be deprecated. - Changed various systems to be triangle-centric rather than polygon-centric, as this is faster. Triangles are presumed to be the elementary face type in a MeshDescription, even if polygons are still supported. The concept of polygons will be somewhat shifted to mean a group of triangles which should be treated collectively for editing purposes. - Optimised normal/tangent generation and FBX import. - Deprecated EditableMesh, MeshEditor and StaticMeshEditorExtension plugins - these are to be removed, but they still have certain hooks in place which need removing. #rb [CL 13568702 by Richard TalbotWatkin in ue5-main branch]
2020-05-28 10:56:57 -04:00
return Iterator ? ElementIDType( Iterator.GetIndex() ) : INDEX_NONE;
}
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
friend FORCEINLINE bool operator==( const TConstIterator& Lhs, const TConstIterator& Rhs )
{
return Lhs.Iterator == Rhs.Iterator;
}
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
friend FORCEINLINE bool operator!=( const TConstIterator& Lhs, const TConstIterator& Rhs )
{
return Lhs.Iterator != Rhs.Iterator;
}
private:
typename TSparseArray<ElementType>::TConstIterator Iterator;
};
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
FORCEINLINE TConstIterator CreateConstIterator() const
{
return TConstIterator( typename TSparseArray<ElementType>::TConstIterator( Array ) );
}
public:
FORCEINLINE TConstIterator begin() const
{
return TConstIterator( Array.begin() );
}
FORCEINLINE TConstIterator end() const
{
return TConstIterator( Array.end() );
}
private:
const TSparseArray<ElementType>& Array;
};
/** Return iterable proxy object from container */
Total revamp of mesh element attribute model. Attributes now have a number of possible types (FVector, FVector4, FVector2D, float, int, bool, FName, UObject*) and are exposed as individual flat arrays, indexed by element ID. For example, vertex positions are essentially exposed as an array of FVector which can be directly accessed and modified. This has a number of advantages: - It is completely extensible: new attributes can be created (even by a third party) and added to a mesh description without requiring a serialization version bump, or any change to the parent structures. - This is more efficient in batch operations which deal with a number of mesh elements in one go. - These attribute buffers can potentially be passed directly to third-party libraries without requiring any kind of transformation. - The distinct types allow for a better representation of the attribute being specified, without invalid values being possible (cf representing a bool value in an FVector4). Attributes also have default values, and a flags field which confers use-specific properties to them. Editable Mesh currently uses this to determine whether an attribute's value can be automatically initialized by lerping the values of its neighbours, as well as for identifying auto-generated attributes such as tangents/normals. This is desirable as it means that even unknown / third-party attributes can potentially be handled transparently by Editable Mesh, without requiring the code to be extended. Certain higher-level operations in EditableMesh have been optimized to make full use of vertex instances where possible. The welding/splitting of identical vertex instances has been removed from here, as the aim is to unify this with mesh utility code elsewhere. Various bug fixes. #rb Alexis.Matte [CL 3794563 by Richard TalbotWatkin in Dev-Geometry branch]
2017-12-07 13:02:12 -05:00
TElementIDs FORCEINLINE GetElementIDs() const { return TElementIDs( Container ); }
};
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
template <typename ElementType>
void TMeshElementArrayBase<ElementType>::Compact( TSparseArray<int32>& OutIndexRemap )
{
TSparseArray<ElementType> NewContainer;
NewContainer.Reserve( Container.Num() );
OutIndexRemap.Empty( Container.GetMaxIndex() );
// Add valid elements into a new contiguous sparse array. Note non-const iterator so we can move elements.
for( typename TSparseArray<ElementType>::TIterator It( Container ); It; ++It )
{
const int32 OldElementIndex = It.GetIndex();
// @todo mesheditor: implement TSparseArray::Add( ElementType&& ) to save this obscure approach
const int32 NewElementIndex = NewContainer.Add( ElementType() );
NewContainer[ NewElementIndex ] = MoveTemp( *It );
// Provide an O(1) lookup from old index to new index, used when patching up vertex references afterwards
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
OutIndexRemap.Insert( OldElementIndex, NewElementIndex );
}
Container = MoveTemp( NewContainer );
}
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
template <typename ElementType>
void TMeshElementArrayBase<ElementType>::Remap( const TSparseArray<int32>& IndexRemap )
{
TSparseArray<ElementType> NewContainer;
NewContainer.Reserve( IndexRemap.GetMaxIndex() );
// Add valid elements into a new contiguous sparse array. Note non-const iterator so we can move elements.
for( typename TSparseArray<ElementType>::TIterator It( Container ); It; ++It )
{
const int32 OldElementIndex = It.GetIndex();
check( IndexRemap.IsAllocated( OldElementIndex ) );
New attribute array API. Fixed some flaws in the original API, deprecated various methods, and introduced some new features. - Now attribute arrays are accessed via TAttributesRef or TAttributesView (and corresponding const versions). These value types hold references to attribute arrays, and individual elements can be accessed by their element ID and attribute index. Using a value type is safer than the previous method which required assignment to a const-ref (and not doing so would take a temporary copy of the attribute array). - The attribute set has been totally flattened, so all attributes of different types are added to the same container. This greatly improves compile times, prevents attributes from being created with the same name but different types, and permits the view feature. - The class hierarchy has changed to have generic base classes where possible with no particular ElementID type. This reduces the code footprint by no longer generating nearly identical copies of templated methods. - A TAttributesView allows the user to access an attribute array by the type of their choosing, regardless of its actual type. For example, the Normal attribute may be registered with type FPackedVector, but accessed as if it was an FVector. This allows us to move away from very strong typing, and instead transparently store attributes of a more efficient size, while the user is not affected. - A transient attribute flag has been added, to denote that a particular attribute should not be saved. #rb none [CL 4226081 by Richard TalbotWatkin in Dev-Editor branch]
2018-07-20 18:58:37 -04:00
const int32 NewElementIndex = IndexRemap[ OldElementIndex ];
// @todo mesheditor: implement TSparseArray::Insert( ElementType&& ) to save this obscure approach
NewContainer.Insert( NewElementIndex, ElementType() );
NewContainer[ NewElementIndex ] = MoveTemp( *It );
}
Container = MoveTemp( NewContainer );
}