hi, so in my profiler, in the game thread this is what taking most milisecs:
This increases when the numbers of pawns on the screen increases, yet i have disabled ticking altogether for all my pawns. So where is this coming from? any help will be appreciated.
This is call after the physics calculation ends. It is a core part of the physics engine (the call itself). If you want to know what is actually taking the time you should expand the item.
Without the actual items inside TG_EndPhysics I would guess that disabling your pawns colliders might reduce it.
this is with all the children opened. From what i researched, the first one-cpu stall-is just time waited for the frame to finish and should be ignored. The second one is more interesting, since it talks about physics but i have cancel all physics in my pawns. I have also canceled ticks yet the tick group still take ms. I also cancelled all collisions. any help on what these things are would be appreciated.
At this point I can only go on the “trail and error” path. If anyone else posts a better idea, listen to them instead.
For now try to disable the Floating Pawn Movement Component.
Just out of curiosity… How… hm, well …big is the ZombieHorde. Try disabling any and all components and start them one by one to find what is causing the issue.
Hi, 3900 pawns all moving individually on the cpu likely won’t be possible, regardless how much you optimize the existing systems. I would rather try to simulate them via a niagara particle system (never done that though).
3900 zombies, each defined as a static mesh component, seems pretty excessive.
You’ll probably want a better way of managing those.
You’ll probably want to use Mass for this, as that’s what it’s for:
Another alternative (used before Mass was available) was to create each entity as a “particle” in Niagara so it can all run on the GPU; it gets only limited interaction with the world that way. It’s used for the beetles in the original 5.0 “not Tomb Rader, we swear!” demo.
