Search Issue Tracker
Fixed in 2020.1.X
Fixed in 2018.4.X, 2019.2.X, 2019.3.X
Performance of NavMeshBuilder.UpdateNavMeshData spike up to 10 times
Steps to reproduce:
1. Download NavMeshTest.zip and open "mytest" scene
2. Start playing in the Editor.
3. Add a plank by pressing "Space" key.
4. Update the NavMesh (NavMeshBuilder.UpdateNavMeshData) by pressing the "A" key.
5. In the Unity profiler, have a look at the respective spike related to the Update.
6. Repeat step 3, 4 and 5
Actual results: Notice that the time taken by the Update varies greatly. On PC with i7-6700k it seems to vary between 2 values: sometimes it takes around ~14ms and other times around ~140ms.
Reproduced with: 2020.1.0a4, 2019.3.0b4, 2019.2.6f1, 2018.4.9f1
May 05, 2020 19:13
Thank you so much for sharing this great blog.Very inspiring and helpful too.Hope you continue to share more of your ideas.I will definitely love to read.
nicaragua travel http://thetravelerswithin.com/
May 03, 2020 18:27
Thanks so much for sharing this awesome info! I am looking forward to see more posts by you!
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
- The Scene\Game view is grey when two "Universal Additional Camera Data" scripts are attached to the camera
- NullReferenceException error thrown when changing Scenes in Play Mode
- Crash on "'anonymous namespace'::ConvertFBXShapes" when importing an FBX file
- Crash on Transform::RemoveFromParent when Object.DestroyImmediate() is called on Transform
- [Linux] Player consumes more CPU resources when it is running in the background
Resolution Note (fix version 2020.1):
The problem is caused by the fact that the height of the bounding volume of all the source geometry changes when we add new objects in the scene, like when adding and stacking new cubes on top of each other or when an object falls indefinitely. The change in height is mistakenly detected by all the NavMesh tiles and not only the modified tiles, thus the build process triggers an update in all the tiles.
Proposed user-side workaround usable immediately:
When preparing the list of source geometry for the NavMeshBuilder.UpdateNavMeshData() function, go and include two dummy NavMeshBuilderSources placed high enough and low enough so that they will forever be above/below any of the other source meshes. Don't exaggerate with the height because this will affect the precision of the build process. Keep the difference in height between them somewhat less than 32000 x navMeshBuildSettings.voxelSize .
They will force the bounding volume of the build process to be stable (the same) during every UpdateNavMeshData. This in turn will stabilize the internal hashes of the NavMesh tiles. If necessary keep these two sources small enough for them to not generate any NavMesh patches.