World Partitioned navigation mesh loading range and tile memory usage

Development Platform & Builds
, ,
1

Hey, I want to reduce memory usage of navigation mesh in a world partitioned world. Right now, this is where I stand:

  1. Recast memory - 160MB
  2. Detour PERM_TILE_DATA - 110MB
  3. Detour Tile Memory - 62MB
  4. Tile cache memory - 42MB
  5. Detour PERM_TILES - 32MB

I have followed this guide - https://dev.epicgames.com/documentation/en\-us/unreal\-engine/world\-partitioned\-navigation\-mesh?application\_version\=5\.5 - and everything works as it is written there. Now:

--- First question:

There’s 1 issue with the way the loading range is decided. Namely:

  1. OpenWorld Template, set up just as in the guide
  2. TileSize 2048
  3. NavigationDataChunkGridSize 2048 (to better see what I mean)

Let’s say I want to load renderable area (landscape, trees) from the main grid in the distance 25600. Then, I want the navigation mesh to be only loaded up to 12800 - I never spawn or control pawns further out. What happens now is that the nav data chunks take the loading range from the grid[0], so they are loaded at 25600. Questions:

  1. Why can’t there be a property in the world settings, right next to NavigationDataChunkGridSize, like NavigationDataChunkGridLoadingRange, which would determine the range at which the nav data loads?
  2. In order to work around it, I have made a new grid, called it “NavMesh” set it’s cell size to 2048 (to match NavigationDataChunkGridSize) and set it’s loading range to the desired 12800 for navmesh. Next, I have modified the “Runtime Grid” property in NavDataChunkActor to use the new “NavMesh” grid.

This is how it looks with no additional grid:

DefaultSetup.JPG

This is how it looks when set up like in point 2 (my desired outcome, minimal necessary navigation mesh loaded):

AdditionalGridSetup.JPG

Point 2 works perfectly, but I don’t like the fact that I have to make a new grid for this. In every guide you write, you are really serious about adding new grids, because they multiply the streaming levels quickly. The nav mesh grid would be everywhere, so that would be whole-world grid, each cell would have an actor.

Also, when I set the runtime grid that way, when building paths all the newly spawned chunks loose the property. So after every rebuild I have to remember to set the Runtime Grid property to the correct grid. Error prone and hard to keep track of, especially in larger studios where more than 1 person handles this.

Are there any planned improvements for this in 5.6? Are there any alternatives? If not, could you please point me to place in code where this range is decided so I could modify source? Or maybe adding a new grid is no longer so bad?

--- Second question:

I would like some clarification on “Fixed Tile Pool Size”. I guess the PERM_TILE_DATA and PERM_TILES in the counters refer to permanent tiles.

  1. Is the fixed pool all allocated at startup of the application and always taking up memory?
  2. Why are you suggesting in several threads in here that this should be used for large worlds? I would expect (when this is set to false) that the navmesh allocates only as many tiles as it needs for the loaded buble for the navmesh and reusing them. So this should only go up into insane numbers if someone wants to load entire navmesh (or vast parts) at once. But if they do, and they clamp that number with fixed tile pool size, then they break their own game, because the navmesh will not be present in the places they would expect to be loaded. Do I understand this correctly?
  3. What are the downsides to shipping game with this set to false?
  4. What does the tooltip for this property mean, that it should be enabled to support streaming? I have tested the point 2 from setup above with this set to false and the streaming works. The screenshots are actually taken with this set to false.

I’d be grateful for clarity on the subject.

2

To your first category of questions, the main answer for all of this is that WP navmesh is still experimental and has not had much development on it further for a few releases. The initial work on WP navmesh support was for a basic system to be authorable and load with the WP cells. I will pass along your feedback for wanting a separate tile loading range to the rest of the team. We are planning to work further on WP navmesh support, but it will be in 5.7 or later.

I can’t speak to all of the recommendations found in the World Building guide for WP grids. It is not my area of expertise, but I would recommend asking another question about that specifically so a member of our World Creation tools team can assist you.

Now to the second list of questions:

  1. Is the fixed pool all allocated at startup of the application and always taking up memory?
    1. Yes. All of the tiles for the pool are allocated when creating the navmesh even if they are not used. This introduces some overhead as empty tiles still have memory impact, but the number of tiles is often adjusted over the project to include maximum needed as well as staying close to the “average” number of tiles in use.
  2. Why are you suggesting in several threads in here that this should be used for large worlds? I would expect (when this is set to false) that the navmesh allocates only as many tiles as it needs for the loaded buble for the navmesh and reusing them. So this should only go up into insane numbers if someone wants to load entire navmesh (or vast parts) at once. But if they do, and they clamp that number with fixed tile pool size, then they break their own game, because the navmesh will not be present in the places they would expect to be loaded. Do I understand this correctly?
    1. We recommend using using a fixed tile pool size to limit memory usage of the navmesh. This can result in missing sections of navmesh in the editor or game, but there are also warnings printed for whenever this happens. It also limits how many tiles are built/displayed in the editor when working with WP maps where loading a large section of the map could load a significant number of tiles that may not be wanted. That is why there is a reminder and warning accompanying the advice to ensure the tile hard limit is enough for the worst case scenario in the game.
  3. What are the downsides to shipping game with this set to false?
    1. There is no large scale negative. It could mean that there are times that there is more memory being dedicated to navmesh than you had budgeted for the game. Games have shipped without that being enabled, but I do not know if games using WP navmesh do not use it.
  4. What does the tooltip for this property mean, that it should be enabled to support streaming? I have tested the point 2 from setup above with this set to false and the streaming works. The screenshots are actually taken with this set to false.
    1. The tooltip includes our recommendation which is to limit the number of tiles for streaming in large world games. This prevents from going over memory budgets. It will work while being set to false, but you run the risk of having a large chunk of memory dedicated to navmesh tiles depending on how things are loaded.

-James