AUTHOR: Mike McGoveran
DATE: 6/9/2023
The Problem:
When building towards our Alpha Build we implemented an AI that was tasked with patrolling our entire level at random. This highlighted the first sign that the built in Character Navigation Component in UE5 was too expensive in performance for our game. The answer was the beginning of retargeting the AI entities to all be a more bare bones class of Pawn Instead of Character. Once this retarget was done we had to implement pawn movement through the PawnFlyingMovement Component. This significantly reduced the load on movement calculations in our map but at the same time our NavMesh showed a sudden performance cost increase of 20-30 FPS. Upon Further investigation I learned that the NavMesh system has issues with long distance pathing requests in a system on the back-end that was only supposed to be temporary over 6 years ago. In addition we are forced into using the fully dynamic NavMesh due to pathing being affected by doors that open and the fact that our level is dynamically created so we can't bake in the NavMesh,
The Solution:
This faced us with 2 choices:
Write our own NavMesh class like other projects have done when using large dynamically generated worlds.
-OR-
Find ways to optimize the current system so the Navmesh can generate paths more efficiently.
Considering the time it would take to dig in and write a new NavMesh system could easily take a week or more to implement and we don't really have the time to dig in so deep due to the college deadline, Writing a new class isn't a good choice. So I decided that it would be best to dig into optimization options. The first thing I found after MUCH digging around is that we could let the NavMesh generate asynchronously on a different thread. while there was a risk that AI would be delayed in getting updates when the thread hasn't adapted to doors changing states it immediately fixed our frame rate issue. The second issue that became clear once this was in effect is that some of our new mobile assets were completely seizing our NavMesh dynamic updates. The cost of recalculating our rotating flamethrower trap completely seizes Unreal's system. The simple fix is to make sure that these traps can't update the NavMesh. once all was said and done the game is no longer hindered by pathing on the AI or the NavMesh system. The only cost to date we've noticed was that at the start of our level it takes a full minute or so to get the NavMesh working over the entire map, but can easily outpace the standard movement rate of the player.
NavMesh Recast Setting that saved us:
Nav Mesh generating during runtime:
cost of over 180 AI roaming our map:
Did you like this post? Tell us
Leave a comment
Log in with your itch.io account to leave a comment.