* Makes it clear that the capture isn't using a realtime view, and prevent materials relying on Time from giving different results based on the time elapsed since the app start
#rb matija.kecman
[CL 27830514 by sebastien lussier in ue5-main branch]
* After the render, test if there are assets pending compilation. If so, wait for compilation to complete and restart the scene capture.
#rb matija.kecman, ryan.schmidt
[CL 27593647 by sebastien lussier in ue5-main branch]
*Added FPrimitiveSceneDesc, a structure you can initialize with a description of the primitive you're trying to Add/Remove/Update in the FScene
-Added entry points in FSceneInterface to do those operations, legacy entry points using UPrimitiveComponent are untouched.
-The code that executes those operations in FScene has been refactored to be shared between the two entry points as much as possible to lessen the additional maintenance burden.
*Added FPrimitiveSceneProxyDesc/FStaticMeshSceneProxyDesc/FInstancedStaticMeshSceneProxyDesc, structures that hold all the necessary information to create a FPrimitiveSceneProxy/FStaticMeshSceneProxy/FInstancedStaticMeshSceneProxy without depending on AActors or UPrimitiveComponent.
-Those structures can be initialized by constructing them with the corresponding UPrimitiveComponents, or by constructing their default versions and initializing the desired fields.
-Creation code for FPrimitiveSceneProxy/FStaticMeshSceneProxy/FInstancedStaticMeshSceneProxy now takes all its info from those desc structures. They are created on demand during scene proxy creation for UPrimitiveComponents. This means no additional memory, and all serialized assets & blueprints are unaffected.
*Added IPrimitiveComponent/IStaticMeshComponent interfaces
-These allow for some editor-only interactions occurring during proxy creation, and serve as a common interface for some code that expected to manipulate UPrimitiveComponent/UStaticMeshComponents. For example FObjectCacheEventSink / FObjectCacheContext now uses those interfaces to associate the resources between various users and interactions like proxy recreation on shader/mesh changes occur through those interfaces.
* Misc
-Moved scene primitive related member variables into a new structure (FPrimitiveSceneInfoData) to facilitate code sharing and implementations of various related functionality (like SetLastRenderTime).
-Changed ObjectCacheContext to store associations between resources and components using component interfaces so that other systems creating proxies have the proper behaviors when resource changes require proxy recreation.
-Added natvis support so that component interfaces to UPrimitiveComponent/UStaticMeshComponent display the component ptr for easier debugging.
-Changed FMotionVectorSimulation to use UObject* instead of UPrimitiveComponent*, it was already using this internally
-Templatized some nanite helpers like ShouldCreateNaniteProxy & AuditMaterials since we need to use them from both UPrimitiveComponent & FPrimitiveSceneProxyDesc and it'll help make sure we keep them in sync.
#jira UE-191990
#rb Zach.Bethel, Ola.Olsson, Jason.Nadro, Krzysztof.Narkowicz
[CL 27200716 by dominic couture in ue5-main branch]
* 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]
* Those where correct, but did manual job to ensure the origin wasn't automatically included in the bounds
#rb jeanfrancois.dube, patrick.enfedaque
[CL 24739720 by sebastien lussier 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]
