Navmesh Cut Performance

I am continuously running into performance issues with Navmesh Cut on recast graph. Each time it takes about 290ms.

My settings:

Cell Size 0.25 (400x400)
Tile size 24
I use Recast Mesh Obj for one plane with all include options off.
Thread Count: Automatic High Load

Profiler data (deep profile):

WorkItemProcessor.ProcessWorkItems() 99.1% total

My game is top down and when a building is constructed I create Navmesh Cut for each wall. I cannot find a better way to do this. I was thinking about using point graph with a recast, but I still need to do navmesh cutting.

Any help deeply appreciated.

Hi

How many navmesh cuts are you using?
How large are they? (i.e how many tiles are they overlapping roughly).
Do you think you could send me a screenshot?
Which version are you using?

290ms does seem very high. In the example scene “Example3_Recast_Navmesh1” cutting the graph using 35 navmesh cuts takes only about 4.5 ms on my computer.

Note that deep profiling slows things down a lot. It is only useful for checking what percentage is spent on some task, not for checking the absolute time taken.

I turned off deep profile and yes time decreased down to about 50 ms. But that does not resolve my problem(normally, fps stays at about 180, while cutting it drops down to 4)

I use four navmesh cuts per building.
The building is modular so I tested different sizes. Building(four cuts) entirely in one tile is in profiler 53ms. The building across 17 tiles took 127ms.

My version is 4.0.10 (2017-05-01).

Buildings will not move so except for deleting it, there is no change to their position.

EDIT:
I created a new scene with camera, plane, and gameobject with a simple script that creates new gameobject with navmesh cut. I still get about 50ms.

EDIT2:
I opened Example3_Recast_Navmesh1,created empty gameobject and added my test script. It had same bad performance (about 80ms).

here is my test script:

using UnityEngine;
using Pathfinding;

public class Test : MonoBehaviour {

public bool create;
// Update is called once per frame
void Update () {
    if(create)
    {
        var obj = new GameObject();
        obj.transform.localEulerAngles = new Vector3(0, 0, 0);
        var col = obj.AddComponent<NavmeshCut>();
        obj.transform.position = new Vector3(10, 0, 10);
        obj.transform.parent = transform;
        col.useRotationAndScale = true;
        col.isDual = true;
        create = false;
    }
}

}

what am I doing wrong?

Hi

  1. Do you think you could change the profiler to use the ‘Hierarchy’ mode instead of ‘Raw Hierarchy’.
  2. When updating the navmesh using a cut the navmesh is processed on a tile-by-tile basis and all navmesh-cuts within a single tile will affect the update. So if you have 100 navmesh cuts in a single tile, if any one of them moves it has to cut that tile while taking into account all the 100 navmesh cuts.
  3. Your script seems to be creating a new navmesh-cut every frame, this will create a very large number of navmesh cuts very quickly. See point 3.
  4. If you try the Example3_Recast_Navmesh1 example scene you can create new navmesh-cuts by pressing the ‘P’ key. What performance do you get when you do that?
  5. Make sure that graph gizmos are not being drawn (‘Show Graphs’ toggle in the A* Inspector). Updating the graph gizmos can often be slower than updating the graph itself.
  1. The script creates new cut when bool create equals true, at the end of creating cut, I make create false - it creates only one object when pressed.
  2. It takes 20ms immediately after pressing P and 46ms when the object hits the ground.
  3. I measure with gizmos turned off.

Screenshot of pressing P and then object hitting ground in Example3_Recast_Navmesh1

Make sure you do not measure just the first time this happens. The first time any cut is done, the JIT-compiler will have to compile all the cutting code which will take some extra time.
The first time a cut happens on my computer it takes 20 ms, but subsequent times it only takes around 2.5 ms.

1 Like

Awesome! I tried and it takes much less time to do it the second time. Thank you very much!

1 Like