Metal 2.3 removed, Metal 3.0 added for Mac
#jira UE-163352
#rb adam.kinge bertrand.carre
#preflight 631ea7eb94758d0bf2008668
[CL 21960671 by axel riffard in ue5-main branch]
Some of these needed full paths after the path lookup changes, some were out of date, and some were typos
#jira UE-161345
#rb matt.peters
#preflight 6306824e5a5d4e462465eaf7
[CL 21566281 by ben zeigler in ue5-main branch]
- Allow different pipelines per asset type so that we don't show all the asset options when importing simple assets likes textures and materials.
- Allow to choose to display the config dialog per asset type so that we can skip it for things like textures.
- Added default stack overrides per asset type.
- Added show config dialog overrides per asset type.
- Added a DefaultTexturePipeline asset which is the Generic Texture Pipeline with the "Import Textures" option hidden.
- Added a DefaultMaterialPipeline asset which is the Generic Material Pipeline with the "Import Materials" option hidden.
- Generic Material Pipeline: Split the import materials option from the type of material to import as so that we can configure their visibility independently.
- Moved the generic texture pipeline from the generic asset pipeline to the generic material pipeline so that we can use the generic material pipeline on its own.
#rb jeanluc.corenthin, alexis.matte
#preflight 63057a415a5d4e4624424ac9
[CL 21529451 by JeanMichel Dignard in ue5-main branch]
-Remove the deprecated WindowsMixedReality and AzureSpatialAnchorsForWMR plugins.
#jira UE-147894
#review-21507768
#rb Robert.Srinivasiah
#preflight 630554dc5a5d4e46243727f3
[CL 21523822 by Jeff Fisher in ue5-main branch]
- Indexing improvements
- No longer asks to auto-create schemes, since we create all schemes needed
- Sped up the run-only project generation to skip a lot of cruft
#preflight 63041e960061f895d0fe3ccf
#rb ian.fox,roman.dzieciol (i am submitting without their final sign-off)
#preflight 63051c23516bef57ffb5b1c2
[CL 21517539 by Josh Adams in ue5-main branch]
#rb Devin.Doucette
#jira UE-161599
#rnx
#preflight 6303c8d65a5d4e4624e7bf52
- There are some use cases that require the VA system to be initialized and configured correctly but would prefer that the backend connections only run if absolutely needed (usually when a payload is pulled or pushed for the first time), this change provides four different ways of doing this:
-- Setting [Core.VirtualizationModule]LazyInitConnections=true in the Engine ini file
-- Setting the define 'UE_VIRTUALIZATION_CONNECTION_LAZY_INIT' to 1 in a programs .target.cs
-- Running with the commandline option -VA-LazyInitConnections
-- Setting the cvar 'VA.LazyInitConnections' to 1 (only works if it is set before the VA system is initialized, changing it mid editor via the console does nothing)
--- Note that after the config file, each setting there only opts into lazy initializing the connections, setting the cvar to 0 for example will not prevent the cmdline from opting in etc.
- In the future we will allow the connection code to run async, so the latency can be hidden behind the editor loading, but for the current use case we are taking the minimal approach.
-- This means we only support the backend being in 3 states. No connection has been made yet, the connection is broken and the connection is working.
-- To keep things simple we only record if we have attempted to connect the backends or not. We don't check individual backends nor do we try to reconnect failed ones etc. This is all scheduled for a future work item.
- If the connections are not initialized when the VA system is, we wait until the first time someone calls one of the virtualization methods that will actually use a connection: Push/Pull/Query
-- We try connecting all of the backends at once, even if they won't be used in the call to keep things simple.
- Only the source control backend makes use of the connection system. The horde storage (http) backend could take advantage too, but it is currently unused and most likely going to just be deleted so there seemed little point updating it.
- If we try to run an operation on an unconnected backend we only log to verbose. This is to maintain existing behaviour where a failed backend would not be mounted at all. This logging will likely be revisited in a future work item.
[CL 21511855 by paul chipchase in ue5-main branch]
#rb Per.Larsson
#jira UE-161296
#rnx
#preflight 62fe3ce73d3fb466b229bcc0
- There are some usecases that require the VA system to initialize the first time it is accessed (usually the first time we attempt to pull a virtualized payload) rather than be initialized in the program start up. This change provides three different methods to achieve this:
-- Setting the define 'UE_VIRTUALIZATION_SYSTEM_LAZY_INIT' to 1 in a programs .target.cs
-- Setting [Core.ContentVirtualization]LazyInit=true in the Engine ini file
-- Running with the commandline option -VA-LazyInit
- If we detect that the source control backend is being initialized on a background thread we do not try to run the FConnect operation. The backend will still work but this does reduce the potential error checking on initialization. This is done because the FConnect operation currently only works on the main thread and to change this would be a bigger work item than we can schedule at the moment.
- UE::Virtualization::Initialize functions now take a EInitializationFlags enum as a parameter. This enum allows the call to ignore all lazy init settings and force the initialization immediately. This is useful for programs like the Virtualization standalone tool which just needs to start the system when needed.
-- The call to ::Initialize in LaunchEngineLoop passes in None and does not ignore lazy initialization.
-- Calls to ::Initialize in the UnrealVirtualizationTool however all use EInitializationFlags::ForceInitialize and ignore lazy initialization settings.
- Fixed an odd bug in UE::Virtualization::Initialize where the error path (if the config file cannot be found) was using a different start up code path.
- Add asserts when assigning to GVirtualizationSystem to make sure that it is null. This is not 100% safe but should catch some potential threading issues, if any.
- Add an assert after lazy initialization (IVirtualizationSystem::Get) to make sure that GVirtualizationSystem was assigned a valid object.
- Improve how we check for legacy values in [Core.ContentVirtualization]. We now support multiple allowed values.
- Added a way to poll if a VA system has been initialize yet or not, this allows us to avoid initializing a VA system if one has not yet been created and we try to:
-- Dump VA profiling stats after cooking
-- Send VA stats to studio analytics
- Note that currently using lazy init loading will probably cause the VA statistics panel not to work, this will be fixed in future work where we will allow the panel to register for a callback when the system is initialized.
[CL 21467510 by paul chipchase in ue5-main branch]
#rb Chris.Babcock
#jira UE-131966
#ushell-cherrypick of 21441862 by dmytro.vovk
#preflight 62fe4c78200ff87e07be431f
[CL 21442825 by dmytro vovk in ue5-main branch]
Notes:
* Model used for the squeeze factor is HorizontalFocalLength = LensFocalLength / SqueezeFactor; VerticalFocalLength = LensFocalLength;
* The renderer renders the desqueezed image directly because of not wanting to add support to maintain non squared pixel.
* Squeeze factor is only hooked in to DOF's CoC.
* Squeeze factor currently also affects depth blur which it shouldn't in theory, requires dual CoC shader permutations in DOF algorithm to do that correctly.
* Crop's model fits an aspect ratio directly into the desqueezed full sensor image.
* Crop settings are directly applied to the camera's FOV calculation of the camera to avoid rendering extra pixels.
* Custom crop aspect ratios can be added into the project's DefaultEngine.ini
#rb colin.benoit, rod.bogart, pat.tubach
#fyi colin.benoit, rod.bogart, pat.tubach
#jira none
#preflight 62fcefe51e39eb26a08cede2
[CL 21424608 by Guillaume Abadie in ue5-main branch]
- Deprecate and redirect USkinnedMeshComponent::SetSkeletalMesh into SetSkinnedMeshAndUpdate.
- Rename SetSkinnedMesh to SetSkinnedMeshAndUpdate to allow default parameter to work in the Blueprints' UI.
#rb Josie.Yang
#preflight 62f62fd723003b62a399dcf8
#jira none
[CL 21353272 by kriss gossart in ue5-main branch]
#rb Per.Larsson
#jira UE-156189
#rnx
#preflight 62f4c098e60c9215b9bcde08
- The orignal name implied tha the payloads would only be stored locally on the users machine, but the intent is to describe a number of backends that are a) faster than the persistent storage backends b) no guarantee that the payload will be found.
- The new name better describes this functionality.
- We still accept 'LocalStorageHierarchy' but will log a warning informing the user to update their graph but this backwards compatibility code will most likely be removed before 5.1 ships.
-- EStorageType::Local will follow the usual deprecation rules.
- Not strictly related to this change but I also cleaned up and added additional loggng during the initialization of the virtualization manager.
[CL 21333601 by paul chipchase in ue5-main branch]
#jira UE-160208
#preflight skip
#rb Patrick.Enfedaque
#ROBOMERGE-AUTHOR: rex.hill
#ROBOMERGE-SOURCE: CL 21323811 via CL 21329084 via CL 21329109 via CL 21329162
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v972-20964824)
[CL 21330359 by rex hill in ue5-main branch]
#rb trivial
#jira UE-156189
#rnx
#preflight 62f3ab2023003b62a324f67a
- The older versions of this value ([Core.ContentVirtualization].EnablePushToBackend and [Core.VirtualizationModule].EnablePushToBackend) will continue to work but will log a warning to the user telling them to update it.
- It is very unlikely that anyone is actually using these old values and so we can remove this backwards compatibility when 5.1 ships. It is only present to allow us to fix up internal projects and to avoid interrupting people testing the system.
[CL 21317383 by paul chipchase in ue5-main branch]
#rb Per.Larsson
#jira UE-156750
#rnx
#preflight 62f212e13b773d04161ee7dd
### Problem
- The payloads stored in map files tend to change more than other assets and would cause a lot more churn in the VA system.
- Some other systems like the landscape component are not able to sensibly continue if their payloads cannot be accessed (heightmaps for exmaple) and would prefer not to allow virtualization.
- As a short term fix we need an option to disable the virtualization on all payloads in map files. Future improvements to the filtering system will allow systems to more easily opt their payloads out of virtualization. When this is functional we might want to change the default from true to false.
### Feature
- The config optionf for this filtering is "[Core.VirtualizationModule]FilterMapContent=True"
- Testing if the owning UObject for a payload is in a umap can get tricky, because we not only need to check the umap but we also need to check if it is in a "_builddata.uasset" file, which is an additional file we store next to a umap containing things like lightmaps etc.
- At the moment we check for this by finding the outermost object for the given owner and check to see if it is a ULevel, UWorld or UMapBuildDataRegistry. This is a bit of a kludge but the types we need to check against are not accessible by this module and making them accessible will pull in a lot of dependencies that we'd prefer not to add.
-- One improvement might be to tag the FLinkerSave with the info we need and passing that into the serialization process rather than trying to work it out ourselves but I am wary of making that change until we are 100% sure that we want to keep this feature.
### Refactor
- Removed IVirtualizationSystem::IsDisabledForObject and replaced it with ::FilterPayload which can return multiple reasons for preventing a payload from virtualizing. (the method was added during 5.1 development so it should be fine to just replace it without deprecation)
-- The original behaviour for FVirtualizationManager::IsDisabledForObject has been moved to FVirtualizationManager::ShouldVirtualizeAsset
- Added a new header to declare enums/types used by the various parts of the virtualization system and started by moving EPayloadFilterReason there from the package trailer header. This allows both the core API and PackageTrailer to use EPayloadFilterReason without creating overburdened header dependencies.
-- EPayloadFilterReason has moved from the UE namespace to UE::Virtualization so the package trailer code needed updating accordingly.
- EditorBulkData will ask the virtualization system for the base filter reason, then add it's own reasons if UE_ENABLE_VIRTUALIZATION_TOGGLE is enabled. This bit of code will be removed for 5.1
[CL 21283179 by paul chipchase in ue5-main branch]
