Search Issue Tracker
Fixed in 2020.1.X
Fixed in 2018.4.X, 2019.2.X, 2019.3.X
Votes
0
Found in
2018.4.0f1
2018.4.2f1
2019.2.0a1
2019.3.0a1
2020.1.0a1
Issue ID
1183826
Regression
No
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
Comments (2)
-
johndd110
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/ -
johndd110
May 03, 2020 18:27
Thanks so much for sharing this awesome info! I am looking forward to see more posts by you!
yaviza http://thetravelerswithin.com/yaviza/
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- "Draw Additional Lights Shadowmap" calls increase when custom MaterialBlockProperty is used
- Crash on _platform_memmove when importing the "Dragon Crashers - URP 2D Sample Project" to a new 2D project
- "Shader is not supported on this GPU" warnings and and shaders are not loading when building the project for non-Chromium browsers
- [iOS][URP] The screen flickers and the "Execution of the command buffer was aborted due to an error during execution" error is thrown continuously
- Shortcut Manager shows empty conflict filter when resolving runtime conflicts involving different contexts
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.