* Fixed a crash that occurred in the baking step when cancelling a scene capture which was triggered by changing an option which invalidated all photo sets (i.e., render capture resolution or capture anti aliasing). This was occurring because the baking step proceeded after the scene capture cancellation and the needed photosets were empty.
* Fixed a crash which can happen if you have no channel enabled, change cleanup tolerance from 0 to 1 and then enable the BaseColor channel. This was fixed by changing the behavior of the Cleanup Threshold property, if its positive the DeviceDepth capture is enabled and its disabled otherwise, previously we also required that another channel was enabled which led to the crash in the baking step. The new semantics are easier to understand in the code and and is probably an improvement to the UX as well since the Cleanup Threshold property behavior does not depend on other properties.
* Improved the scene capture cancellation: Users can now cancel the scene capture when the tool is starting up which is better UX since if they picked slow settings they don't intend to reuse, the capture can be cancelled, also, the code is simpler. Changed the behavior of the BakeRC tool properties so that after cancellation the completed captures with the desired settings are enabled. The old behavior where cancellation was documented to restore old results was broken and cannot be made to work unless we store the old results in a separate scene capture but for high capture resolutions that would require a lot of memory. When the SceneCapture is cancelled the channels which were pending and didn't complete are logged in the Output Log in case the user forgets which ones were enabled.
* Simplified the code in various places: Added `operator[](ERenderCaptureType)` to structs with per-capture data, and use it to simplify many places where we previously checked channels individually. Added conversion functions from tool properties/geometry script parameters to the render capture parameters. Removed old confusing logic that determined if a capture had been updated by tracking the number of photos in each photoset with a new system based on a new per-capture pending state. Deprecated a bunch of functions which are no longer useful or which used the wrong types (e.g., `FRenderCaptureUpdate` was added because I hadn't noticed `FRenderCaptureTypeFlags`). Changed the defaults in `FSceneCapturePhotoSet` so that the DeviceDepth capture is off, its an advanced feature and the defaults are intended to make the class friendly to new developers
#rb lonnie.li
[CL 26569987 by matija kecman in ue5-main branch]
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]
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]
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]
ToolsFramework:
- added new USceneSnappingManager::ExecuteSceneHitQuery API function, as well as accompanying FSceneHitQueryRequest/FSceneHitQueryResult structs
- added FSceneQueryVisibilityFilter struct which contains ComponentsToIgnore/InvisibleComponentsToInclude lists for snapping queries and provides shared IsVisible() implementation
ModelingComponents:
- add FLevelObjectsObserver, tracks Actors added/removed to a Level via various editor events
- add FSceneGeometrySpatialCache, maintains spatial data structures for known types of mesh-backed PrimitiveComponents, an octree based on their world-space bounding-boxes, and provides various spatial-query functions
- ModelingSceneSnappingManager now maintains a FSceneGeometrySpatialCache for a set of Actors/Components it is notified about, and updates the spatial cache if those components are modified or translated. Currently supports Volumes and DynamicMeshComponents.
- add ModelingSceneSnappingManager::ExecuteSceneHitQuery implementation, does raycasts into the world (for static mesh components) and FSceneGeometrySpatialCache for Volumes/DMCs
- modified ModelingSceneSnappingManager::ExecuteSceneSnapQuery to also do combined query against StaticMeshComponents via world-linetrace, and FSceneGeometrySpatialCache for Volumes/DMCs
- add ToolSceneQueriesUtil::FindNearestVisibleObjectHit variants that take a USceneSnappingManager or UInteractiveTool, and do queries via the SceneSnappingManger, instead of directly linetracing into a UWorld
ModleingToolsEditorMode:
- add FLevelObjectsObserver instance and use it to drive updates to active ModelingSceneSnappingManager
#rnx
#jira none
#preflight 61a664a09a226d9e823ad4c1
#ROBOMERGE-AUTHOR: ryan.schmidt
#ROBOMERGE-SOURCE: CL 18339853 in //UE5/Release-5.0/... via CL 18339869
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v895-18170469)
[CL 18339891 by ryan schmidt in ue5-release-engine-test branch]
