Focus is specifically on the NavMesh data creation, making it more flexible and able to cover many more use cases. The changes are based on feedback we’ve collected over the last year via 1:1 conversations, forums, alpha/beta testers and at events like Unite.
What has Changed?
Multiple agent sizes are now supported. And the workflow is now based on components
New High Level Components:
• NavMeshSurface - Describes a volume where the NavMesh will be built, you can have multiple volumes, at any orientation
• NavMeshLink - Allows to connect two NavMeshes with a wide link
• NavMeshModifierVolume - allows to change the area type of the NavMesh which falls inside the volume
• NavMeshModifier allows fine grained control of area types per Game Object.
These components are open-sourced (MIT license) – see link below
Everything above is built on top of a simple public API which allows you to pass in the geometry that will contribute to the NavMesh building.
Low level script API:
• A method to quickly collect render or physics geometry for building NavMesh.
• method to build NavMesh Data from the sources, optionally asynchronously.
• method to incrementally update the existing NavMesh data locally
• you can pass in your own data: Meshes and simple primitives.
• instances of NavMesh Data can be added and removed at any time for any position and orientation.
• The query API has been extended to support query filters based on agent type as well as area mask/cost.
Supported Use Cases
Bake NavMesh and store it in a prefab.
Bake NavMesh at runtime (i.e. for user generated content).
Bake NavMesh for multiple agent sizes.
Bake NavMesh on a surface for any orientation.
Bake NavMesh only within a specified volume.
Continuously update the NavMesh around a moving character.
Instantiating and connecting NavMeshes with different positions.
Update NavMesh locally at runtime.
Feedback
Feel free to comment and ask questions in this forum. Issues with workflow and bugs can be reported here as well. However, a bug report with a minimal repro case is more likely to be tracked and solved than a forum post.
I have been using the new navmesh components and the improvements are monumental. I am highly considering switching our navigation solution to this.
I see there is a specific use case which is NOT supported on the github, and that is a moving navmesh. Is this something you will support in the future? We have several use cases for a moving navmesh and it would be one of the only big features missing that we would like to see.
Yes - it’s planned.
It will require an extension to the NavMeshInstance API to (.Move).
Currently: simply translating the position will not work - as it doesn’t affect the carried agents.
UpdateNavMeshDataAsync is simply kicking off a background thread to build the navmesh from the input sources that are passed, it’s not using the physics system but its own rasterizer etc. The returned AsyncOperation can be used to check the progress.
Looking at the bug (847408) now. Prefab support is difficult when referencing and creating assets
It leads to a question: how do you imagine yourself working with navmesh surfaces on prefabs ?
• Do you prefer a scene with a number of prefab instances that you’re working on (applying).
• Prefabs don’t have separate scene(s) - they are updated in-place.
• something else.
It’s a bug, clicking Bake triggers an apply change to the instanced prefab and a bunch of other weird things outlined in the bug log.
All are fine and depend on which stage of the project I’m in. I like to work from the prefab in the project view usually when I need to go numerical or normalize similar prefabs (example adding a component or baking data) AND if I don’t need to preserve soft link with the asset. If I do need to preserve link to asset or nested prefabs then I work from a mega scene with tons of prefab blueprints, which offer the advantage of allowing Bake All (which will be added soon, I’m sure ;), sometimes I work from the scene when I prototype and move quick like the thunder.
Another question. I have been playing with the orientation abilities of the navmesh and have been trying to find a way to support a crawler agent, one that can crawl on ceilings mainly and perhaps walls. I have tried achieving this by making a level or set of geometry one hierarchical object, then flipping it upside down, baking the navmesh, re-orientating the level back and then re-orientating the navmesh to fit. This has worked but I can’t figure out if its possible to orient the navmesh agent to use a navmesh in this way. In my attempts the navmesh agent errors on not being ‘on’ the navmesh so, using SetDestination fails.I doubt this is supported but if it is how would you go about achieving this effect?
It would be nice to be able to bake the navmesh along a certain orientation and allow for agents to path in non-normal ways.
2D can mean many things (top down , side-scroller, otho-depth).
If you mean - can the navmesh be baked in the x-y plane rather than the x-z plane then yes.
Arbitrary orientations are supported - check out the NavMeshSurface component.
Currently there’s no support automatically extracting 2D colliders but it is planned. However,
using the low level API “Mesh” input is supported – so if you’re building navmesh from something that can be represented as a mesh - there is a way.
I’m not sure i understand the question - but any orientation is supported when baking. If you use the navmeshsurface component, you’ll see that the y-axis of its transform is the local (navmesh) up-vector. There should be no need to rotate-bake-counterrotate, although that is supported.
Oh, I did not realize that it was indeed baking orientated based on the way I set up one of my tests. Apologies for the confusion and thanks for that clarification. Everything is working now and the agents orient properly to all the navmeshes. Awesome. What a game changing improvement to the navigation system. Thanks a ton Jakob.
Looking at the low level doc I read "Note: We believe that automatic generation is the only way to create robust navigation data. As such, we do not allow the users to directly create NavMesh polygons themselves. ".
Could you expose a way to connect the existing data to a skinmeshrenderer - creatures crawling on a giant creature.
Also is there a spherical/cylindrical baker in the work? Or a way to program the orientation vector as a function of the sampler position?
Overall I like how you’re handling wide links, didn’t see a part about auto generating these, do you have a plan to support multi navmesh auto linking?
I also ran some benchmark and it seems you sped up the path solver or changed the collision avoidance maybe? they seem to interpenetrate more than it used to be in 4.7
Does this allow script-only access ie. agents that are not a component on GameObject, but created and updated from a script and included in the navmesh system?
