Search Unity

Digging path navmesh performance issues

Discussion in 'Navigation' started by cangkts, Apr 1, 2021.

  1. cangkts

    cangkts

    Joined:
    Mar 5, 2020
    Posts:
    6
    Hello, im trying to build a demo where player can dig the path and the navmesh agent goes through it. So i was looking at terrain deformation and stuff but instead of that, i decided to build cubes with sticks. Every cube has 16 sticks. So when raycast happens, i create a circle and destroy every stick in the circle like this ; https://imgur.com/a/IUuIKe2. The real problem starts when i start to dig.

    So sticks has carve enabled navmesh obstacle. When i try to dig, it goes 100 fps to nearly 10 but works like how i want. I tried navmesh surface with no carve and buildNavMesh() after raycast but navmesh agent just goes through cubes.

    I want to know if i can optimize it, if yes how?

    profiler image :https://imgur.com/a/sMsx5oF

    Edit: i lowered stick amount in cubes to 8 and now the fps is stable. if this is not the way to go, please answer.
     
    Last edited: Apr 1, 2021
  2. Egad_McDad

    Egad_McDad

    Joined:
    Feb 5, 2020
    Posts:
    39
    You could try replacing
    BuildNavMesh()
    with
    UpdateNavMesh()
    using a coroutine:
    Code (CSharp):
    1. public IEnumerator UpdateNavMeshAsyncCoroutine()
    2. {
    3.     var operation = mySurface.UpdateNavMesh( mySurface.navMeshData );
    4.     do { yield return null; } while ( !operation.isDone );
    5. }
    6.  
    7. // start the coroutine elsewhere
    8. StartCoroutine( UpdateNavMeshAsyncCoroutine() );
    Additionally, try using multiple, smaller surfaces so that there is less work to do for any single change. Thirdly, using a list of
    NavMeshSource
    and passing it to
    NavMeshBuilder.UpdateNavMeshAsync()
    might also be more performant.

    Edit: Also found that
    NavMeshBuildSettings
    allows you to specify the number of worker threads for the baking to use, by lowering this I think you potentially make it perform better at the expense of a longer time to update. I'm not sure how good of an idea this is though
     
    Last edited: Apr 6, 2021
    PutridEx likes this.