This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
External functions should no longer access FVectorVMContext directly and instead use the helper member functions in the NiagaraDataInterfaceFunctionContext class... this should have zero effect without NIAGARA_EXP_VM defined... if it is defined then it'll use the experimental VM functions, which are not included in this CL.
#rb shaun.kime #jira none #okforgithub public
#ROBOMERGE-SOURCE: CL 16908052 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v836-16769935)
[CL 16908059 by shawn mcgrath in ue5-release-engine-test branch]
-changes the function table to be an array of function pointers to allow for the redirection without copies/reallocations
-eliminates 2nd most common allocation in cases with large instance counts in niagara
#rb stu.mckenna
#ROBOMERGE-SOURCE: CL 12146347 via CL 12146348
#ROBOMERGE-BOT: (v659-12123632)
[CL 12146350 by rob krajcarski in Main branch]
#RB Rob.Krajcarski, Stu.McKenna
#JIRA UE-84463
#ROBOMERGE-OWNER: arne.schober
#ROBOMERGE-AUTHOR: arne.schober
#ROBOMERGE-SOURCE: CL 12105113 via CL 12121713
#ROBOMERGE-BOT: (v657-12064184)
[CL 12121717 by arne schober in Main branch]
The code used to update the output ID to index table, but that left stale entries in the input buffer set. When particles died, one of the buffers had -1 for the dead IDs, but the other still had the old execution indexes. This could lead to direct reads returning bogus data, instead of reporting that the ID is no longer in use. The solution is to clear the ID table at the beginning of the tick, and let the UpdateID() function fill in the IDs which are still in use.
This problem didn't occur on GPU, where the tables were already being cleared.
#rb none
#ROBOMERGE-SOURCE: CL 11292467 via CL 11292468
#ROBOMERGE-BOT: (v647-11244347)
[CL 11293007 by mihnea balta in Main branch]
The UpdateID CPU kernel didn't take into account the instance start offset, so the spawn step mapped new IDs to indices starting at 0. If the emitter already contained particles, this caused the ID to index mapping to be incorrect in the frame when the spawn happened, which caused further problems if another emitter tried to read the particles in that frame.
#rb none
#ROBOMERGE-SOURCE: CL 11290626 via CL 11290627
#ROBOMERGE-BOT: (v647-11244347)
[CL 11290628 by mihnea balta in Main branch]
