#jira UE-47471
#rb Fred.Kimberley
#lockdown Cristina.Riveron
#ROBOMERGE-SOURCE: CL 5810777 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5810780 by marc audy in Main branch]
#jira none
#rb none
#ROBOMERGE-SOURCE: CL 5810213 in //UE4/Dev-Editor/...
#ROBOMERGE-BOT: ENGINE (Dev-Editor -> Main)
[CL 5810216 by chris gagnon in Main branch]
The previous path used to parse the world and generate all shaders at once,
which created a massive stall. This happened immediately after choosing the mode.
For example, following "viewmode shadercomplexity"
The new implementation generate only what is currently being used in the rendering.
Added some visual feedbacks to show missing (pending) shader status in shader complexity.
Added "r.ViewMode.ShaderTimeSlice" to control how much time is spent per frame to generate the viewmode shaders.
#rb daniel.wright
#ROBOMERGE-SOURCE: CL 5805353 via CL 5805355 via CL 5805356 via CL 5805440
[CL 5805445 by uriel doyon in Main branch]
#rb andrew.rodham
#lockdown nick.penwarden
#jira UE-72362
#ROBOMERGE-SOURCE: CL 5798956 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5798960 by max chen in Main branch]
#jira UE-72428
#rb frank.fella
#lockdown nick.penwarden
#ROBOMERGE-SOURCE: CL 5795010 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5795014 by max chen in Main branch]
An assertion fired up when SSCSEditor::AddNewComponent() was called in a loop (or multiple times in the same frame) with every component scheduled to get the focus. This unexpectedly activated the 'create + rename' transaction mechansim multiple times but only one item (the last in the frame) would end up being focused, scrolled into view and renamable on creation. Instead of asserting, if an ongoing transaction is ongoing, assumes it is because AddNewComponet() is being called in a loop, close the previous transaction and open a new one, expecting the last component added in the frame (with focus request) to close its own transaction once scrolled into view and edited by user.
#rb Marc.Audy
#lockdown Nick.Penwarden
#ROBOMERGE-SOURCE: CL 5790810 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5790816 by patrick laflamme in Main branch]
New AssetRegistryState::InitializeFromExistingAndPrune temporarily disabled until some bugs have been fixed.
Test Scenario:
1) BuildCookStageAndRun with these arguments: -platform=Win64 -configuration=Development
2) CookIterate with these arguments: -run=Cook -CookCultures=en -TargetPlatform=WindowsClient -unversioned -stdout -unattended -iterate
Wall Time Results (as an average of running step 2) two times):
Before: ~09:40 (580 seconds) cook commandlet time
After: ~02:30 (150 seconds) cook commandlet time
=> 07:10 (430 seconds ) faster, i.e. a ~ 3.9x speedup
Win32 FileSystem Results:
Before: 1.5 million GetFileAttribute calls and 1.2 million FindNextFile calls
After: 35 0000 GetFileAttribute calls and 1.6 million FindNextFile calls
=> ~400 000 calls to FindNextFile replaces ~1.5 million calls to GetFileAttribute
#rb none
(peafour-cherrypick of //UE4/Dev-Core/[at]5645695 by PJ.Kack)
#ROBOMERGE-OWNER: robert.manuszewski
#ROBOMERGE-AUTHOR: pj.kack
#ROBOMERGE-SOURCE: CL 5533504 via CL 5533655 via CL 5536177 via CL 5772728 via CL 5772753
[CL 5772793 by pj kack in Main branch]
#rb: Martin.Wilson
#jira: FORT-113893
#ROBOMERGE-SOURCE: CL 5768200 via CL 5768201 via CL 5768840 via CL 5770648
[CL 5770764 by lina halper in Main branch]
#jira UE-72097
#rb matt.hoffman
#lockdown nick.penwarden
#ROBOMERGE-SOURCE: CL 5766589 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5766590 by max chen in Main branch]
- Proper updating of Heightmap Colllision
- Multiple Undo/Redo fixes
#rb richard.malo
[FYI] michael.dupuis
#jira UE-72277: Fixes Undo/Redo of weight maps when not using the new Layer System
#ROBOMERGE-SOURCE: CL 5766185 via CL 5766372
[CL 5766405 by patrick enfedaque in Main branch]
