When memory is limited, the GraphPartitioner in Nanite's building code can run out memory from within the METIS library. This is currently not properly raised as an OutOfMemory error in our memory subsystem, which means that we are missing those in our error reporting for memory issues. We are already aborting when this happens, so there is no behavior change besides that the error is now properly picked up by our reporting systems.
#rb Brian.Karis
[CL 31207388 by sebastian schoner in ue5-main branch]
* Previous fix was skipped for non local assets that needed a redirector
#jira UE-198460
#rb JeanFrancois.Dube
[CL 31184245 by sebastien lussier in ue5-main branch]
When adding plugin directories also add any valid plugin extension directories (inspired by cl 24072232).
Don't filter out plugins disabled in the editor/cooker, they may still be enabled on the target platform.
todo: Reintroduce more accurate plugin filtering logic.
#rb dan.engelbrecht, Zousar.Shaker
[CL 31167561 by pj kack in ue5-main branch]
We need to control how the process handle is opened.
#jira UE-205151
#rb stefan.boberg, Zousar.Shaker
[CL 31127942 by dan engelbrecht in ue5-main branch]
This allows you to attach an automatic fix to any error or warning that may arise from eg. validation.
#jira none
#rb Julien.StJean
#ushell-cherrypick of 31124509 by gabriel.wreczycki
[CL 31126352 by ben hoffman in ue5-main branch]
BuildSkeletalMeshChunks is used during cooking when saving skeletal meshes (calls originate from USkeletalMesh::BuildLODModel, see linked jira ticket for full callstacks) and deduplicates overlapping vertices. In contrast to many other places in the engine, it is using a multimap instead of the FOverlappingCorners type. Using a multimap is technically more correct since "points overlap each other" is not an equivalence relation (it is not transitive, i.e. "A overlaps B" and "B overlaps C" but "A does not overlap C" is possible). FOverlappingCorners pretends that transitivity is given, because that is pretty much always true. Note also that there is another check later on for whether two vertices within the same cluster actually overlap.
In especially degenerate cases this can save a lot of memory because we only store each group of overlapping vertices once (instead of having a copy for every vertex in that group). With user content in UEFN, it is unfortunately very much possible to hit these degenerate cases, allocate gigabytes of memory, and have the cooking process terminate with an OOM error.
This CL changes this codepath to use FOverlappingCorners instead. The memory savings and time savings are significant, find a comparison here https://docs.google.com/document/d/1qHnY_6WXpcEmJL_61myQDczxG6XDZRuVUCE8yQ-FkDs/edit?usp=sharing
#rb alexis.matte, laura.hermanns
[CL 31119331 by sebastian schoner in ue5-main branch]
#rb mark.lintott
#jira UE-165045
#rnx
- Add a new event (GetAnalyticsRecordEvent) to the UE::Virtualization namespace. Different telemetry systems can hook into this and respond when the virtualization system tries to send a new analytics event.
-- This even accepts an enum class of flags to provide better context for the event. At the moment the only valid flag is to request that the telemetry system flushes the event to make sure that it is sent before returning control to the event. In this way we can know that events are safely recorded before terminating the current process.
- To begin with we are only adding failure events and not recording any successes
-- Send an analytics even when the initial connection to perforce fails, the event should note if the user opted to retry their connection (after entering new details) or if they wanted to skip the check and load the editor anyway.
-- Send an analytics event when a payload fails to pull, the event should note if the user opted to retry to pull the payload or quit the process.
[CL 31087065 by paul chipchase in ue5-main branch]
