Problem with Navmesh and doors

Legacy UDK Programming and UnrealScript
1

I want to use Navmesh in interiors but there are a problem with doors.

Here is a video to show:

I’m using UTscout.uc, and the bots are extending from Pawn.uc, and using controllers extending from AIController.uc.

The Paws are using drawscale=0.5 and the cylinder is 15x45.

First problem, the navmesh are not generating paths through the doors. I had to modify UTscout.uc, adding this lines:

NavMeshGen_StepSize=15.0
NavMeshGen_MinEdgeLength=15.0

Now there are paths through doors, and fill the interior, at the cost of bigger times to build.

Second problem, the bots are not passing through the doors. The FindPath() are not working with them.

In the video, the girl (the bot) draws a debug sphere green when is moving using navmesh, and red when is not using (using movetoward).

You can see in the video part 1 that the girl cant find a path when the player is in the interior of the room.

I have tried to change a lot of things, pathsizes in the scout, values in GetNextMoveLocation, and giving some values to NavMeshPath_SearchExtent_Modifier… not working none.

Then I have tried to reduce the pawn drawscale, from 0.5 to 0.25, and it works. The small bot pass the doors. Also I had to change this in the scout:

PathSizes(3)=(Desc=Common,Radius=10,Heig­ht=44)

(original Radius are 100). (I don’t know why are affecting the “Common” instead “Human”).

So tried to return to pawn drawscale to 0.5 and set the “common” radius to 5. Not worked. Radius = 20, not worked.
I don’t understand very well how the navmesh works.

I have found a solution that works, but I don’t like very much.

Just before calling FindPath(), the cylinder radius of the bot are divided by 2, from 15 to 7.5. A timer restore the normal radius 0.01 seconds later.

The FindPath() then makes the bot can pass through the doors. You can see in the part 2 and 3 in the video.

But I don´t like this solution, so the question is, are some way to get the same result with some magic values in the scout or any way to pass to the navmesh the half of the cylinder radius without change the cylinder in game each time?

(The awesome scify laboratory is a test map called “MegaTile”, donwloaded from here: http://www.torfrick.com/ . Using dynamic lights in this video and loaded as stream level on the island map).

2

I guess you could try and add a couple of path nodes either side of the doors, select the 2 nodes then right click on 1 of the nodes, select the Path Options and the try a Force Path. Rebuild the paths.

I gather the paths will show a blue line (narrow path) between the 2 path nodes.

3

I don’t see the “force path” option, there is with another name?

I have tested with pathnodes and findpathtoward() instead pylons and the problem is the same, the path fails in doors and others, like the pylon. So I think that is a problem relative to the scout and the pawn scale.

With this values in scout:

NavMeshGen_StepSize=15.0
NavMeshGen_MinEdgeLength=7.0

works better in some doors without reducing the cyllinder, but still have problems in other places.

I’m thinking about make a custom actor to place at doors and complicated sites, that forces the bot to pass the door, since I can’t ride with Navmesh.

4

If you only select 1 path node then right click on it you wont get the force path option from force path (needs 2 nodes selected so it knows which nodes to force a path between).

With 2 path nodes selected in editor right click on 1 of then : Path Options>Force Paths

5

Ah, I was looking in the pathnode properties… thanks.

It works, but I have the same problem that using Navmesh. The problem is not generating paths, which are correct, the problem is when usign FindPath() (or FindPathtoward() using pathnodes).

I think that the engine thinks that the pawn are wider and don’t find the path. All works fine if I reduce the Pawn cyllinder radius to the half, call to FindPath() and then restore the cylinder radius. The pawn find the path correctly.

The pawns are using a drawscale or 0.5, and probably the FindPath() function thinks that the drawscale is 1. So if the real radius is 15, FindPath() thinks that is 30 and don’t resolve the path if the space is not enought wide.

I’m looking for a way to fix that, to no use the trick of reduce the radius before calling FindPath(), but I don’t see anything in the scout relative to the drawscale or the radius.

I saw some relative to get cylinder bounds, but it’s native. So I don’t know how to tell to FindPath() that the pawn scale is 0.5 and the real radius is 15, not 30.

6

I guess another hack solution is where you could adjust the collision of the mesh to make it wider then add in some blocking volumes which block the player but not the AI by configuring so the bot and pathing ignores the blocking volume

7

Yes, but it’s more simple the actual trick, to reduce the cylinder radius before calling FindPath(). So you don’t need to modify anything in the map.

I’m looking this:

/* UDKScout uses the properties from this class (jump height etc.) to override UDKScout default settings */
var class<Pawn> PrototypePawnClass;

that points to UTpawn in the UTScout. I have changed to my pawn class (extending scout) but not working. Then I have added a drawscale=0.5 in UTpawn, but not working… FindPath() are always use the wrong pawn radius. If this radius is half, then it works.

8

Just spotted this … [Strange issue with nav mesh] Can't find path if cylinder is too high. Why? - Epic Games Forums

9

Yes, it seems the same problem, but with the height. I only need to reduce the pawn radius to work correctly. I think that is because the pawn drawscale is 0.5 instead 1, and the FindPath() multiplies by 2 the radius.

10

I’ve not looked at the code but is the path sizes array mentioned in the post only for height? Is there not an equivalent of the array for width?