Search Issue Tracker
Won't Fix
Votes
2
Found in [Package]
2.0.0-pre.3
Issue ID
NAVB-7
Regression
No
Navmesh is not baked on the ends of Terrain when it's inside of a volume on the very edge
Reproduction steps:
1. Open the attached project "BugTests.zip";
2. Open the navmesh.unity scene;
3. If it's not baked, go the Navigation tab and bake the Navmesh.
Expected results: as there are two terrains and accordingly there are two Navmesh surfaces, there should be continuous Navmesh after baking it.
Actual results: the Navmesh has a little split between two surfaces.
Reproduced on: 2017.2.0b1, 2017.2.2p3, 2017.3.2f1, 2017.4.1f1, 2018.1.0f1, 2018.2.0b1.
Not reproduced on: 5.6.6f1, 2017.1.3p3, 2017.2.0a4.
-----
The NavMeshSurface Volume is indeed a bit too strict and it does not detect (intersect) the neighbouring terrain that is a small distance away, not even 0.001 units. Thus the NavMeshSurface only takes into consideration the terrain inside the volume and, because of that, it leaves out a margin of agent-radius size in the NavMesh at that edge of the volume. We will fix this.
By increasing the size of the volume by just a bit (on the Z axis in this case) the other terrain can be detected and the NavMesh extends out to the volume's boundary.
Please note that the NavMesh surfaces generated by each individual NavMeshSurface component are completely separate and they can never be unified into one continuous NavMesh, even if they overlap. The only way to allow a NavMeshAgent to move from one surface to another is by connecting the surfaces with a NavMeshLink or an OffMeshLink.
The only way to have one single NavMesh surface to extend over both terrains is to extend the Volume to include them both.
-
pdhr
Apr 19, 2020 07:24
Also still persists in 2019.3 (specifically 2019.3.6f1)
-
Hsni
Apr 18, 2019 06:22
Issue still persists in unity 2018.3.6. So annoying.
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
- Crash on ShaderLab::ShaderState::ApplyShaderState when entering Play Mode and calling ShaderWarmup.WarmupShaderFromCollection with a shader that has dynamic_branch
- Crash on operator delete[] when a serializable structure in the System namespace is serialized by a MonoBehaviour
- [macOS] forward and backward mouse buttons are recognized as middle mouse button
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
Resolution Note:
The NavMeshSurface Volume is indeed a bit too strict and it does not detect (intersect) the neighbouring terrain that is a small distance away, not even 0.001 units. Thus the NavMeshSurface only takes into consideration the terrain inside the volume and, because of that, it leaves out a margin of agent-radius size in the NavMesh at that edge of the volume.
By increasing the size of the volume by just a bit (on the Z axis in this case) the other terrain can be detected and the NavMesh extends out to the volume's boundary.
Please note that the NavMesh surfaces generated by each individual NavMeshSurface component are completely separate and they can never be unified into one continuous NavMesh, even if they overlap. The only way to allow a NavMeshAgent to move from one surface to another is by connecting the surfaces with a NavMeshLink or an OffMeshLink.
The only way to have one single NavMesh surface to extend over both terrains is to extend the Volume to include them both.