- Will hopefully prevent races between the generation and SCWs.
- Startup impact: ~2ms (when files are up to date) to ~7ms (when they aren't).
#rb Jason.Nadro
#jira UE-115409
[CL 16326113 by Arciel Rekman in ue5-main branch]
- The mirage specific code is disabled behind the define UE_USE_VIRTUALBULKDATA, this means that some code paths in Texture/Mesh are much more complex than they need to be as we support both old and new paths. Once the system has been turned on and confirmed to cause no issues then this will be stripped out.
- SavePackageUtilities.cpp, SavePackage.cpp and SavePackage2.cpp are editgrates rather than integrations as those files have changes in DevCooker that we don't want to bring over immediately.
- Also includes a prototype system for storing bulkdata in a sidecar file in the workspace domain rather than in the .uasset/.umap file which although has been discontinued as part of mirage, will have applications for future work for non-virtualized projects and/or text based assets.
#rb Patrick.Finegan (all changes have been reviewed when submitted to Dev-Cooker)
#tests Cooking and running ShooterGame/Frosty and other sample programs using megascan assets
#rnx
#preflight 608be50d870cf400013ff99d
[CL 16167285 by paul chipchase in ue5-main branch]
- A single call to FAssetCompilingManager::Get().FinishAllCompilation() is now sufficient to ensure every asset in the editor has finished compiling.
- Dependencies are now used to determine asset compiler ordering
- Implement interface and unify some functionality between these assets
- MeshCards
- DistanceFields
- SkeletalMeshes
- StaticMeshes
- Shaders
- Textures
#rb Francis.Hurteau
#preflight 6086d3668de3a6000124c2b0
[CL 16122343 by danny couture in ue5-main branch]
StopThread() waits until all stat tasks are executed. Now that we use a pipe instead of StatsThread, the pipe asserts in its destructor if there're any unexecuted tasks. Seems like before unexecuted tasks were just dropped.
[CL 16103643 by Andriy Tylychko in ue5-main branch]
#fix pre-load animation data controller module, and replace Load with GetModule in AnimSequenceBase::GetController
#rb devin.doucette
#ROBOMERGE-SOURCE: CL 15878380 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15878394 by jurre debaare in ue5-main branch]
In a previous change TraceAux::Initialize was moved to a point very early in process lifetime. At this point the config system is not ready, so resolving data driven channel presets does not work. To solve this we make two changes, define two presets in code (default and memory) which require very early application, and add a second pass of channel initialization which is executed directly after config system is up.
#rb martin.ridgers
#ROBOMERGE-OWNER: johan.berg
#ROBOMERGE-AUTHOR: johan.berg
#ROBOMERGE-SOURCE: CL 15822904 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v785-15821902)
#ROBOMERGE-CONFLICT from-shelf
[CL 15829754 by johan berg in ue5-main branch]
1) TlsAutoCleanup: in the previous version `FTlsAutoCleanup` used `FRunnableThread` to store registered instances and to delete them on `FRunnableThread` destruction. This means that all threads that are not created by `FRunnableThread` (the game thread in particular, and all 3rd-party threads) never delete registered `FTlsAutoCleanup` instances. This change moves the storage from `FRunnableThread` to TLS to cover all threads
Thsi change can break systems that implemented a workaround for this problem, e.g. by manually deleting registered `FTlsAutoCleanup` instances on the game thread exit, as now this instances will be deleted twice. The solution is to remove the workaround and to rely on uniform `FTlsAutoCleanup` behaviour on all threads.
#rb steve.robb
2) removed CpuProfilerTrace workaround to handle the fact that FTlsAutoCleanup leaks on the game thread, as this is fixed by (1).
#rb martin.ridgers
Need to submit both parts together as they need each other
#robomerge Release-5.0-EarlyAccess
[CL 15624597 by Andriy Tylychko in ue5-main branch]
- The Expected Work This Frame 25 value was arbitrarily picked.
#rb Arciel.Rekman
#jira none
#ROBOMERGE-SOURCE: CL 15608695 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v777-15581079)
[CL 15608704 by jason nadro in ue5-main branch]
#rb jeanfrancois.dube
#ROBOMERGE-SOURCE: CL 15520686 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v771-15082668)
[CL 15520732 by richard malo in ue5-main branch]
Avoid static mesh queuing any more work during shutdown to improve exit speed
#rb JeanFrancois.Dube
#robomerge Release-5.0-EarlyAccess
[CL 15510067 by danny couture in ue5-main branch]
This will help ensure that the first triggered stall, the one that sends telemetry data, will represent a real stall witnessed by a person. This will also shutdown the stall detection thread sooner to alleivate any coupling with other engine systems.
#rb francis.hurteau
#jira UE-108804
#preflight /job/6034575e17838200011a148f
#ROBOMERGE-SOURCE: CL 15497038 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v771-15082668)
[CL 15497095 by geoff evans in ue5-main branch]
- Creating the shader directories relies on the process having a valid project but was being called before we validate the project file.
- This meant that if the project path is invalid instead of getting a clear error dialog about it the user would hit a fatal log while generating the shader directories instead.
- We can safely move the code to a point after the project path has been validated as nothing will have tried to access the list of shader directories yet.
#jira UE-109024
#rb Arciel.Rekman
#rnx
#ROBOMERGE-SOURCE: CL 15491659 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v771-15082668)
[CL 15491661 by paul chipchase in ue5-main branch]
