Hello!
We are currently building an open-world game with a WP system, and we want to use nav invokers because we have dynamic elements in the world.
We are currently facing multiple problems :
- Current memory consumption for the invokers is way too high due to the necessity of having all the octree in memory
- We want to reduce CPU usage as much as possible when building the navmesh, so we were wondering if it is possible to have a base version of the navmesh baked and used by default by the invoker, so we only have to rebuild dirty areas and not the entire navigation at runtime.
- We also want to use the lock as much as possible to avoid rebuilding navigation all the time, but we still want navmodifiers to affect the navmesh while geometry changes are locked.
So, do you have any tips for us to solve those problems?
[Attachment Removed]
Current memory consumption for the invokers is way too high due to the necessity of having all the octree in memory
I would try to remove navigation relevant from as many actors and meshes as possible. An aggressive approach is the best way to reduce navigation octree memory. You could also look into using lazy data gathering mode. Using that, the octree element is still created but its modifier data is not gathered until needed. This could save some on memory, but removing nodes/elements altogether is the best way to do this.
We want to reduce CPU usage as much as possible when building the navmesh, so we were wondering if it is possible to have a base version of the navmesh baked and used by default by the invoker, so we only have to rebuild dirty areas and not the entire navigation at runtime.
This is not available in the engine as is. You could look at creating something like this similar to how we handle WP dynamic navmesh that loads a base navmesh that can then be updated. We also use a base navmesh with dynamic generation for FNBR that uses a regular navmesh. Doing it with invokers is not something we have done. You would likely need something to identify what exists in the base navmesh to know if the invoker needs to rebuild tiles that are streamed in to ensure navmesh matches current geometry.
We also want to use the lock as much as possible to avoid rebuilding navigation all the time, but we still want navmodifiers to affect the navmesh while geometry changes are locked.
The lock blocks all rebuilding including modifiers. The locking system would need changes done for if a rebuild was allowed based on the reason for rebuild. You may look into creating your own subclass of ARecastNavmesh and add an override in RebuildDirtyAreas that checks whether the flag for the dirty area is a dynamic modifier. Then you could call the Super method with only the collected modifier areas. This could all be contained in a branch using a boolean that you can change during runtime to share when a full rebuild is possible.
-James
[Attachment Removed]