You've already forked UnrealEngineUWP
mirror of
https://github.com/izzy2lost/UnrealEngineUWP.git
synced 2026-03-26 18:15:20 -07:00
b4814d732d
- 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]