- When adding a new channel: Only the newly requested channel is captured, previously all enabled channels were (re)captured
- When removing an already captured channel: We no longer recompute all remaining channels, we just wipe the one that was removed
#rnx
#rb ryan.schmidt
#preflight 6372120fbf76990b71f17750
[CL 23115901 by matija kecman in ue5-main branch]
Tested compiling fortnite, unrealeditor, lyra, qagame with non-unity/pch
#preflight 63635997876630122adeab9f
#rb none
[CL 22958990 by henrik karlsson in ue5-main branch]
This fixes a problem that occurs in both the Render Capture Baking tool and the Approximate Actors tool
#rb arciel.rekman,ryan.schmidt
#rnx
#jira UE-146097
#preflight 62fa24791e61d1ba0e294d83
[CL 21408934 by matija kecman in ue5-main branch]
Also removed artefacts that became visible after the ones fixible with a depth test were resolved. These were related to linearly interpolating data on the photosets, this was fixed since the baking framework is where texture filtering should take place
#rnx
#rb lonnie.li, ryan.schmidt
#jira none
#preflight 62d473b0dc4397d384a06bc8
[CL 21148985 by matija kecman 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]
