* Removed deprecated or dead code paths
* Simplified build system setup for physics support
* Deprecated build system flags and unsupported macros
#jira none
#rb Chris.Caulfield, Kriss.Gossart
#preflight 62963ec0fe779f23c8ea0c5e
[CL 20450744 by Benn Gallagher in ue5-main branch]
Tidy up use of FPrimitiveSceneProxy velocity getters.
Now DrawsVelocity() is only for velocity relevance.
And HasDynamicTransform() is for determining if we need to store previous transform state.
VSM caching was using PRIMITIVE_SCENE_DATA_FLAG_DRAWS_VELOCITY so replaced that with PRIMITIVE_SCENE_DATA_FLAG_SHOULD_CACHE_SHADOW which should use the old behavior and can be tweaked in future using ShouldCacheShadow().
A common pattern for determining whether to output velocity now is to check if a previous transform exists, and to OR in AlwaysHasVelocity().
I found some proxy types that don't check for previous transform.
Also I found that the debug physics aggregate types *never* check for previous transform.
These are pre-existing potential bugs for fixing in another pass.
Also I found some proxies that don't currently fill out velocity relevance.
These are pre-existing potential bugs for fixing in another pass.
#preflight 62863f789016c6dd897f1cd2
#fyi andrew.lauritzen
[CL 20279797 by Jeremy Moore in ue5-main branch]
* TriangleOffsetArray range must be [0, NumTriangles)
#jira UE-151762
#rb patrick.enfedaque
#preflight 6283ab394316db80d18e2ad9
[CL 20242244 by Sebastien Lussier in ue5-main branch]
Benchmark configuration:
- Test scene with 4 meshes: a mossy stone nanite mesh, a beach ball, a ball with an emissive blue cross and a hut mesh
- Target mesh: 11.8k triangles mesh, created by voxel wrapping the meshes in the test scene elements
- 4096x4096 output texture with 16x multisampling baking BaseColor, Emissive, PackedMRS and Normal maps
- 4096x4096 photo capture resolution
Unreal Insights reports the following times for the Bake call:
- Before this change: 2 mins 45 seconds
- After this change: 55.9 seconds
Aside: (Unaffected by this change) In both cases the photo capture, which is done on the game thread, took about 1 min
#jira none
#rb
#rnx
#preflight 627e64e01748fbc85bb24a42
[CL 20221383 by matija kecman in ue5-main branch]
- add FStaticMeshLODResourcesAdapter in MeshConversions module, wrapper that presents StaticMesh LODResources mesh (ie Section buffers) with an API compatible with GeometryCore mesh templates
- add TMeshWrapperAdapterd in GeometryCore, this is a shim for getting any template-API-compatible mesh into a FTriangleMeshAdapterd specifically (required to call some non-template mesh processing functions)
- add support for using StaticMesh LODResources meshes in FMeshSceneAdapter instead of source meshes, controlled by build options flag
- add FMeshSceneAdapter build options flags specifying whether UV/Normal queries are required (default true)
- when not required, the loaded MeshDescriptions and created DynamicMeshes are packed into FColliderMesh which has a smaller memory footprint, allowing the larger meshes to be freed
- to support above, the SpatialWrappers in MeshSceneAdapter.cpp have been refactored extensively
- added FCompressedMeshSpatialWrapper which Builds from a temporary FDynamicMesh3 into a FColliderMesh, supports all the same options as FDynamicMeshSpatialWrapper (so a drop-in replacement with less memory usage, but no UV/Normal queries)
- added FBaseMeshSpatialWrapper, base class for existing FDynamicMeshSpatialWrapper and new FCompressedMeshSpatialWrapper that has shared config settings (can more more here in the future)
- added FStaticMeshLODResourcesMeshSurfaceAdapter, similar toFMeshDescriptionTriangleMeshSurfaceAdapter, a mesh adapter that filters out any geo that doesn't have a Surface-domain material
- refactored TStaticMeshSpatialWrapper into TStaticMeshSpatialWrapperBase and subclasses FStaticMeshSourceDataSpatialWrapper and FStaticMeshRenderDataSpatialWrapper, for source mesh vs render mesh
- added FCompressedStaticMeshSpatialWrapper, variant of FStaticMeshSourceDataSpatialWrapper that stores to a FColliderMesh and releases the source MeshDescription
- SpatialWrapperFactory() now has logic to build from render mesh vs source mesh vs compressed source mesh
- moved initial SpatialWrapper construction from AddActors() phase to Build() phase, because now it depends on build settings
- add EMeshDataSourceLODPolicy to IGeometryProcessing::FOptions, with LOD0 Source and LOD0 RenderMesh options
- ApproximateActorsImpl now provides/handles this policy setting, and configures FMeshSceneAdapter to not need UV/Normal queries (not required in this context)
- add bUseRenderLODMeshes option in FMeshApproximationSettings to expose render vs source mesh control at user level
#rb sebastien.lussier, rinat.abdrashitov
#jira UE-141256
#preflight 6206db44054c2e38c473be5d
#rnx
#ROBOMERGE-AUTHOR: ryan.schmidt
#ROBOMERGE-SOURCE: CL 18963126 in //UE5/Release-5.0/... via CL 18963829 via CL 18964587
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v917-18934589)
[CL 18964607 by ryan schmidt in ue5-main branch]
#ROBOMERGE-AUTHOR: ryan.schmidt
#ROBOMERGE-SOURCE: CL 18952618 via CL 18953740 via CL 18954339
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v917-18934589)
[CL 18954439 by ryan schmidt in ue5-main branch]
