This seems like a fairly popular question so I thought I’d go ahead and give an answer based on my understanding of the navigation system. Note I am on a source build of the engine based on version 4.26.
Default Query Extent
Before we talk about what the default query extent does, we need to know a little bit about how the engine does AI navigation. When you place a Nav Mesh Bounds Volume into the editor the engine will create a set of navigation polygons based on the geometry inside of the Nav Mesh Bounds Volume. You can see these nav areas in the level by Show → Navigation. Additionally there is a project setting you can turn on to see the individual polys Project Settings → Navigation Mesh → Draw Poly Edges.
When you tell an AI to move using MoveTo the engine will find a starting poly (wherever your AI is standing) and then attempts to find an end poly that is close to the location you told the AI to move to. The engine will then calculate the shortest path between the start and end polys and the AI will follow that path.
The default query extent is used to help us find the end poly. Let’s say you had a big level with over a 100,000 polygons. Searching through every single polygon to find the one that is closest to the location you told the AI to move to is going to take a non-trivial amount of time. In order to speed up the process, the engine wants you to tell it how far in each direction to look for a polygon before giving up, which is the purpose of the default query extent.
The default query extent defines the size of a rectangle to find polygons in. The extent is used in both the pathfinding code and things like ProjectPointToNavigation. If I set my default query extent to x=100, y=100, and z= 500, and then tell the AI to move a x=0, y=0, z=0, the engine will look for a polygon that is within a rectangle 200 units long, 200 units wide, and 1000 units tall with a center at x=0, y=0, z=0. The size of the rectangle is double what you set because if you set z=500, it will look 500 units in the up direction and 500 units in the down direction, hence a rectangle that is 1000 units tall. You can see the size of the default query extent if you place a Navigation Testing Actor into your scene.
What size should I set the default query extent to then? Let’s look at an example to answer that question. Suppose you have an AI and you want it to move to the player who is standing at x=2000, y=2200, z=0. For the sake of this example let us also say there is a nav poly right under your player at x=2000, y=2200, z= 0. By default the engine uses a query extent of x=50, y=50, z=250, so if you tell the AI to move to your player the move will succeed because the nav poly is within the extent rectangle. But now let’s say your character jumps to x=2000, y=2200, z=700. All of a sudden your AI will not be able to navigate to the player because your navigation poly is no longer within the rectangle. The poly has a z=0, your player is at z=700, and the extent only goes down 250 units. So if you then set the extent to x=50, y=50, z=1000, your AI would be able to move to your player who is at x=2000, y=2200, z=700 because the rectangle extends 1000 units downward and now encompasses the nav poly under the player.
In the original question the reason setting z=25000 caused the AI to start walking up and down the hill is because @MemphisSnakes most likely told the AI to go to a point that was either too high or too low, and the default value of z=250 did not encompass any navigation polys.
So the size you set the default query extent to should be the largest size you need for your game to work while being as small as possible. The larger the size of the default query extent, the more polygons it will encompass, and the longer it will take to process. Additionally, there is a limit of 128 polygons in the engine source, so if your extent covers more than 128 polys, the behavior may be undefined as to which one it will use in path finding. Note that I don’t think increasing the Z value of the extent will have much impact on performance unless your level has a lot of vertical polygons.
Nav Agent Radius
Let’s talk a little about what Nav Agents are. I like to think of Nav Agents as a set of rules that describe which AI are allowed to use a given path. You can add custom agents under Project Settings → Navigation System → Agents, but the engine comes with a default agent out of the box. If you only have a single agent or are using the engine’s default, all of your AI will use that agent, regardless of their size (for better or worse). I would only add multiple agents if you have specific AI behavior in mind; let me walk through an example of what I mean by that.
Let’s say we’re building a city level in a shooter game. The city has roads and alleys which the AI can walk on, and alleys are much narrower than the roads. We have two enemy types, tanks and foot soldiers. Soldiers should be able to navigate on both the roads and alleys, but tanks should only be able to navigate on the roads. For the sake of example we’ll say that roads are 3000 units wide, alleys are 500 units wide, soldiers have a capsule size that is 100 units wide, and tanks have a capsule size that is 1000 units wide.
We place a bunch of Nav Mesh Bounds Volumes in the level to setup navigation, and we add a single agent to our project settings. But here’s the catch, because we have only a single agent in our project settings, all of our AI will use the same Nav Agent, which is the only one we have defined.
So we start the game, what happens? The soldiers will work as we intended because they are able to fit on both the roads and alleys, but because we only have a single Nav Agent, the tanks will also try to go down the alleys. And because the alleys are only 500 wide and the tanks are 1000 wide, the tanks will get stuck, blocking the path. This is where having multiple agents comes in.
To fix this we would go to project settings and create an agent called “SoldierAgent” and one called “TankAgent”. We would set the Nav Agent Radius of the “SoldierAgent” to 100, and we would set the radius for the “TankAgent” to 1000.
We would then go back into the level, and adjust the supported agents of each Nav Mesh Bounds Volume by going to the Details panel under Navigation → Supported Agents. For the Nav Mesh Bounds that make up the alleys we would set Supported Agents to “SoldierAgent”. For the roads we would set the Supported Agents to both “SoldierAgent” and “TankAgent”.
Now this time when we start our game, the engine will attempt to assign a Nav Agent to both the soldiers and tanks based on their capsule size. Since the capsule size of our soldier AI is 100, they should be assigned the “SoldierAgent”, and the tanks will be assigned the “TankAgent”. I don’t know the exact math used to figure out what agents are assigned to what AI, but it is based off of the capsule size of the AI.
Because the alleys now specify only AI that are assigned the “SoldierAgent” are able to navigate the alleys, the tanks will no longer attempt to navigate down the alleys. Basically, the Nav Agent Radius is a generalized way to tell the navigation system “Hey, this path should only be used for AI with a capsule of this size”. But again, this only works if you have multiple agents. If you only have a single agent all of the AI will use that agent. (How do I associate my character with a Navigation System Agent? - Programming & Scripting - Unreal Engine Forums)
In the original question @MemphisSnakes asks about why only a value of 35 appeared to work for the Nav Agent Radius. This actually has little to do with the Nav Agent Radius. Most likely what happened is this: when you hit play in editor, the engine will check all the recast nav meshes in the level and add their navigation information to the navigation data. This happens in a function called RegisterNavData (NavigationSystem.cpp). One of the checks in this function is that the configuration for a given recast nav mesh is equivalent to one of the supported agents.
If you place a Nav Mesh Bounds Volume in the level when the agent in your Project Settings had a Nav Agent Radius of 35, the volume will build a recast nav mesh and copy that agents configuration with a value of 35. If you then change that value to 10, when you press play in editor, RegisterNavData will check that the configuration of the recast nav mesh is equivalent to the one in your Project Settings, and will see that 35 != 10. When this happens none of the navigation data will be saved because the engine thinks the recast nav mesh does not support any agents. Because there is no navigation data the AI is unable to move. But if you then set the value back to 35 in the Project Settings, 35 == 35 so when you play in editor the navigation data will be saved because the configuration matches the project settings and the AI will be able to move again.
In short, if you place a Nav Mesh Bounds Volume in the level and then change agents in the Project Settings, remember to “Build Paths” in the build menu of the editor. This will ensure that the configuration of the recast mesh matches your agent settings.
Nav Agent Height
The essay I wrote above about Nav Agent Radius also applies for the height as well. If you had a doorway that was 200 units tall, you could specify that only AI with a capsule height of 200 could use that doorway by setting the Nav Agent Height in the Project Settings, and then specifying the supported agents in your Nav Mesh Bounds Volume.
Again, the reason why the AI did nothing when @MemphisSnakes changed the value from 144 to something else is most likely because the recast nav mesh and Project Settings agents were out of sync. Just remember to Build Paths from the build menu and you should be fine.
Conclusion
Wow that was way longer than I expected. Key takeaways:
- Use default query extent to increase how far away to look for a navigation polygon when you use something like MoveTo. Just don’t make it too big otherwise performance will be impacted
- All AI will use the same Nav Agent if you only have one
- Use Nav Agent Radius and Height along with multiple Nav Agents to tell the navigation system what AI sizes are allowed to use which paths