The crash that was fixed occured when, for example, the userturned off a capture channel while the baking background compute was running
The refactoring has enabled the tool to only bake the newly captured channels only, previously when the scene capture was incrementally updated all pre-existing channels were baked again
The refactoring should enable us to more easily support a feature where the user toggles capture directions or adds new ones manually
#preflight 63c02c46345a532dfc273e6a
#rb lonnie.li
#rnx
[CL 23663959 by matija kecman in ue5-main branch]
- 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]
