Thanks a lot on the explaination! Really helpful! Also, one small thing slightly skipped is that, by default, the NavMeshSurface has the "Use Geometry" set at "Render Meshes". That's kinda crazy and wasteful because, obviously, the collisions are rarely based on the rendered mesh. Switching the option to "Physics Colliders" will make things a lot faster and less prone to unplanned issues. As an example, I'm dynamically generating a 3D world for a side-scroller game and if I'm not setting the option to "Physics Collider", the updated navmesh includes all the stuff around. Another cool thing about the NavMeshSurface component is that it gives you the ability to update separated navmesh data if, for example, you want a navmesh for something like background characters and a navmesh for the player's area. You can place the NavMeshSurface component on the parent of a prefab that gets instantiated and call its BuildNavMesh with "Collect Objects" set for "Children". This way, you can limit the NavMesh to be only be updated from the content of the prefab itself. The way the NavMeshSurface works is that it stores its own NavMeshData (or one you set up for it) and at the end of the "BuildNavMesh()" call (or when you press "Bake" in the component within the inspector), it gives a reference to the Navigation Navmesh so that when an agent is calculating a trajectory, it also check for that reference (additional navmesh data) if it's reachable. As such, it's also possible to store/cache the NavMesh data generated by a NavMeshSurface and reload when needed instead of baking it again. This can be really useful for a project where you know something will happen to the NavMesh (like before and after a bridge broke down) and instead of baking the whole complex NavMesh during playtime, you can bake them in the editor, set the data aside and load whichever you need. (When you press "Bake" in the NavMeshSurface, it generate a folder next to the active scene with the scene name, if not already there, and put the NavMesh Data inside that folder.)
Those using 2022 it is already installed in your project by default and no longer in experiment mode. I just found it out upon watching this tutorial and checking my project the old Navmesh is also obsolete and moving into this new navmesh system.
The problem is that the navmesh surface component doesn't just build for itself or it's mesh but builds for EVERYTHING which I don't know why it does that at runtime because in editor it's just confined to the mesh itself
Following along step by step, I'm getting a "he type or namespace name 'NavMeshSurface' could not be found (are you missing a using directive or an assembly reference?)" even though I have all the same components you have. Any idea?
Hi, Great tutorial. NavMesh Components is an extremely stable and useful addon to the native navigation system. The one thing that is the limitation of this approach is that you can not bake a height map in runtime. Without a height map, my agents are floating above ground. Is there a way to make a height map in runtime or to force characters walk on the ground?
Mon dieu, mes oreilles saignent. Tu prononces "Engine" comme "Vagina". MDR Merci pour la vidéo quand même and not thank you for the horrendous accent :-)
Thanks a lot on the explaination! Really helpful!
Also, one small thing slightly skipped is that, by default, the NavMeshSurface has the "Use Geometry" set at "Render Meshes".
That's kinda crazy and wasteful because, obviously, the collisions are rarely based on the rendered mesh. Switching the option to "Physics Colliders" will make things a lot faster and less prone to unplanned issues.
As an example, I'm dynamically generating a 3D world for a side-scroller game and if I'm not setting the option to "Physics Collider", the updated navmesh includes all the stuff around.
Another cool thing about the NavMeshSurface component is that it gives you the ability to update separated navmesh data if, for example, you want a navmesh for something like background characters and a navmesh for the player's area. You can place the NavMeshSurface component on the parent of a prefab that gets instantiated and call its BuildNavMesh with "Collect Objects" set for "Children". This way, you can limit the NavMesh to be only be updated from the content of the prefab itself.
The way the NavMeshSurface works is that it stores its own NavMeshData (or one you set up for it) and at the end of the "BuildNavMesh()" call (or when you press "Bake" in the component within the inspector), it gives a reference to the Navigation Navmesh so that when an agent is calculating a trajectory, it also check for that reference (additional navmesh data) if it's reachable.
As such, it's also possible to store/cache the NavMesh data generated by a NavMeshSurface and reload when needed instead of baking it again. This can be really useful for a project where you know something will happen to the NavMesh (like before and after a bridge broke down) and instead of baking the whole complex NavMesh during playtime, you can bake them in the editor, set the data aside and load whichever you need.
(When you press "Bake" in the NavMeshSurface, it generate a folder next to the active scene with the scene name, if not already there, and put the NavMesh Data inside that folder.)
Thanks very much for showing how to update NavMesh dynamically.
Those using 2022 it is already installed in your project by default and no longer in experiment mode.
I just found it out upon watching this tutorial and checking my project the old Navmesh is also obsolete and moving into this new navmesh system.
It's already like 5 year and navmesh is not updated yet, like wth unity
thanks
i was looking for something exactly like this
wish unity documented experimental packages better
5 Years and still "Experimental" haha.. thanks unity.
The problem is that the navmesh surface component doesn't just build for itself or it's mesh but builds for EVERYTHING which I don't know why it does that at runtime because in editor it's just confined to the mesh itself
In a 5km x 5km scenario, how do you partition navmesh, and join them?? (just to avoid to bake all the world, for a small change on a single terrain)
Did you find an answer
@@juanalvear6592 unfortunatly no :(
Did you find an answer? I'm trying to solve the same problem right now
@@juanalvear6592 no :(
@@egemenayhan7737 no :(
Thanks, this was exactly what I needed! Tested with 2021.3.6f1
Hello! I'm making a city manager, where I need to build buildings. When is the best time to call the build function?
After instanciating a building i'd say !
Following along step by step, I'm getting a "he type or namespace name 'NavMeshSurface' could not be found (are you missing a using directive or an assembly reference?)" even though I have all the same components you have. Any idea?
I have the same issue
using Unity.AI.Navigation; and if someone uses script inspector 3, they have to compile it in visual studio.
when putting the update mesh as you did to update it in runtime it gives me lag and I can't move in the game
for me the bake and object windows arent there
Hi,
Great tutorial. NavMesh Components is an extremely stable and useful addon to the native navigation system. The one thing that is the limitation of this approach is that you can not bake a height map in runtime. Without a height map, my agents are floating above ground. Is there a way to make a height map in runtime or to force characters walk on the ground?
Thanks a lot ! My project is in unity 2020.3. Will this package work with it? When I import the package, I don't see the NavMeshSurface script
very useful, thanks :)
so from what u said u can use it to make player build houses the AI can walk on right?
Yes that is the point of the navmesh being dynamic
@@codefriendgamedev thats great, been looking for this for a while just wasnt sure how to search for it, thanks!
nice vid, thanks
Thanks
Mon dieu, mes oreilles saignent. Tu prononces "Engine" comme "Vagina". MDR Merci pour la vidéo quand même and not thank you for the horrendous accent :-)