Welcome! - New NavMesh Features Experimental Preview

New NavMesh Features Overview

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.

Everything to get started is available here: https://github.com/Unity-Technologies/NavMeshComponents

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.

 

This is great! Does UpdateNavMeshDataAsync use raycast to build?

A bug #847408

 

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.

 

Thanks!

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.

 

Its great stuff!
Do you have some release plans or/and date?

 

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.

 

Does it work with Unity's native 2D solution?

 

Awesome!

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.

 

Have you considered making some parts of navmeshes oneway? This would help in creating routes for pedestrians for instance.

 

No - and IIRC this is the first time I've seen that request. It would have to affect the tessellation of the navmesh to work properly i suppose.

 

Can you make it work on regular beta builds soon?

 

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

collision avoidance soup

 

Is this be integrated with the new multi-threaded transform update?

 

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?

 

Not as part of this drop - but it is planned to have Low-level script API backing all components.

 

Eventually yes - near future, but it's not in this drop - and definitely not in 5.5

 

No plan for navmesh to follow a skinned (animated) mesh - i think a node graph might perform much better in that scenario - but clearly depends on the scale difference etc.

Varying up vector for a navmesh surface is not supported - and not planned. It's a request that comes up rarely (but is now +1). The implications are non-trivial - many optimizations and simplifications result from the planar representation of the navmesh, so maybe it requires a separate system. However, if your "planet" is big enough and you need only navmesh for a local region it might suffice to rebake the navmesh around the region of interest - using its local up-vector.

Apart from performance improvements caused by better job granularity for threaded update and a couple of other minor improvements, not much has changed wrt performance. I'll try to see what could cause differences in penetration - IIRC we didn't change behaviour there.

 

I took a bit of a gamble switching from my engine to unity, contingent on you guys getting this AI improvement shipped. I'm glad to see it finally arriving. My game has been designed with these capabilities in mind and I was able to plug the new system in nicely to everything I've pre-arranged.

I use a grid of thousands of cells that batch and hold meshes generated and modified during play. I've setup the nav mesh by creating one instance that is built over the entire map, which consists of 3000 procedurally generated mesh cells, terrain and other game objects. When a mesh is updated, I run the asynchronous rebuild and it seems to be performing well with dozens of active AI. So far everything seems to work well for my medium-large scale, single-map based system. The only issue I encountered was a crash on update when I first set things up (before the crashed there was an error, reading something like "assert oldSomethingBlocks == 0"). However, it may have been due to me accidentally passing something to the mesh data that shouldn't be, since I am no longer getting these errors. If I encounter it again during what I believe to be proper implementation, I'll be sure to report it.

That being said, I was wondering, is there any plan to allow manual dictation of what tiles are to be updated? When I implemented recast in my own engine, I set the map up such that the individual tiles corresponded to my map cells. This had some advantage for large scale implementations, although the hash check seems to be sufficiently fast.

I was also experimenting with the mesh links. It seems that for cell-to-cell linking of nav meshes, it would be a rare occurrence for irregularly-shaped, procedurally generated meshes to take advantage of the mesh links. Are there any other linking mechanisms you guys have looked at?

Overall, top notch work, thanks and regards!

 

This one is interesting. The bound parameter of an UpdateNavMeshDataAsync overwrites the entire meshData instead of keeping things that were previously computed out of the bounds so you can't use that - Jakob, shouldn't update add to things out of the bounds? Mad could then do what he wants: localized updated. I ran some tests thinking that UpdateNavMeshData only rebakes around the sources that were changed but that's not the case, it rebakes everything in the bound volume (ouch). There is room for optimization.

 

Thank you!

Manual control over which tiles to bake has been considered, and we could add it. However, the reason for everything updating in one go - is to ensure neighboring tiles to match consistently. E.g. imagine you change the build-settings - say tile size or voxel size - and then update. If tiles are updated separately - you'll have old and new tiles mixed - and since the tiles no longer match up - it will be difficult to reason, control and debug how things behave.

We looking into auto-connecting different meshes - but realized that we could spend a lot of time ending up with a solution that might work for most cases - but for an unknown number of corner-cases it wouldn't. So we decided to spend our time on the other parts and focus on shipping that.

Regarding the crash: It shouldn't crash ofc. no matter what geometry you might have passed. I'll have a look - would be great to have a repro. or crash-log/callstack. please submit a bug if you encounter it again, then PM me w. the case number - or post it here. I'm guessing the error must've been: assert oldAddedTileRefs == 0 ?

 

Hmm, That's a bold claim - only tiles of the navmesh that are changed should update ofc. that's the basic idea.
A tile is recomputed if: build-settings have changed _or_ the intersection of the tile-bounds and build-bounds have changed _or_ if the input sources have changed. Otherwise we keep the existing data.

I'll be interrested in a repro. case that demonstrates rebaking when none of criteria above are true.

 

The title mentions AI and Navigation, are you planning on adding AI related features?

For example in a fps battle game NPC's could detect cover behind walls. This could be done a number of ways, voxel based data combined with occlusion data that can be scanned for cover profiles. This could be baked into the data dynamically or configured manually with a tag or layer.

Or say there is a narrow beam over a dangerous drop that NPC's would need to line up on before crossing.

Or just parkour style level navigation, jumping, leaping, climbing, rolling, sliding.

PS will the new navigation system allow for 3d spaces, so Underwater, Flying or in Space levels with 6DOF will just work?

 

We'd like to add more AI features - reasoning included - but no concrete plans for what to do first.
Regarding 3D pathfinding - no, not as part of this feature Do you have a concrete use-case ?

 

It would be really useful for some of the 3D games I've made...

Enemy AI that could navigate in 3D using 6DOF would be great for this style of game, especially for games that want to be able to dogfight through and around structures e.g.

Or do trench runs!

 

In terms of software software design, this makes sense. Advanced users can make use of lower level access but it adds the risk of errors a user can not trace into the black-box portion. Based on the speed of subsequent navmesh updates, I'm pretty sure it is rebuilding only the edited sections. I don't think I've seen the issue laurentlavigne mentioned but I'll measure the update times when I get a chance.

Right, this is always problematic and requires some tedious coding to test for updates. In that sense, the hash function provides a simpler solution. From what I've played around with so far, mesh connection seems less important than the current feature set. Instead of generating separate cells for an open world environment, it seems to be easier to regenerate the navmesh from the players current location, as in your tracking examples. From there, any AI outside the loaded world I can consider "out-of-scene" and delegate that to the long-range AI manager. The ability to generate as many separate nav meshes and agents allows me to create a simplified version of the world in an isolated layer and run pathfinding for out-of-scene AI; then I can respawn them when they are back "in-scene". The current feature set seems to be quite flexible.

I'm also looking into the possibility of an AI agent to traverse from terrain to a vehicle navmesh. If I can get this to work, I'll be quite content.

Yes, that's the error I was receiving. I will see if I can reproduce the error later tonight.

 

Here is the repro based off "drop plank": latest spawn only affects one tile. 100ms spike on the non async rebuild indicates more than a tile rebuild because full build of the entire scene is 114ms.
[EDIT] dropping a plank sometimes spikes less than 100ms, as low as 50ms but as soon as you drop a plank outside of existing tiles, huge spike occurs.

In the same scene "drop plank", something odd happened after I unparented the camera from the character: the agent cannot move in some of the tiles, the navmesh system pathese to the edge of the tiles that work, any idea what causes that?

I logged a bug for both, maybe some rat died in the gears of the scene 848380

 

allright - thats strange highest spike here is 1ms - in a debug build, also GC alloc looks disturbing - i have 24 bytes, coming from the async operation.

 

What if the 2D navmeshes could work in 3D space...

In a descent type game with 6DOF movement, we could set up navmeshes along the tunnel walls. The NPC drones could then use this system to find where to go to and how to get there. It would need a loosening of the grounded/proximity settings to allow them to move down a tunnel without hugging the walls and some vectoring feedback to reduce/prevent collisions.

Would that work?

For more open spaces a simple waypoint system should do, with obstacles having avoidance beacons.

Although a voxel based navmesh grid would be ideal for combining air and ground units e.g. in big cities or toroidal space stations.

Q: Has anyone stress tested the navigation mesh on a Wipeout style racing track with really high speeds?

 

These new features are awesome, they give more freedom and less headache to developers.
Before this update I used to bake Navigation Mesh on Run Time in script but was confused when found that it wasn't working in build. Thanks to this update it's not a problem anymore.

However, I found that horizontally moving surfaces with Navigation Mesh on them, don't keep Agent if they're moving a little faster than speed of snail. So do You have any suggestions on how to keep Agent on moving horizontal surface?

 

This look really neat!

We're using the current navmesh solution in our project, and it's a bit of a pain, so proper improvements are really nice! I especially look forward to having seperate surfaces - we've got water-based agents and land-based agents, and when water comes up against land, the water agents moves halfway onto land and vice-versa. We also have to accept big enemies clipping walls or small enemies walking too far away from walls, both of which look bad, so suport for several sizes sound amazing.

I've read through the docs, and it might be beacuse it's 1:30AM, but I'm confused by some things:

- You're saying that you're supporting several sizes of agent, but what does that mean? Does the agents with different sizes need different surfaces, or can a single surface support several agents?
- Are there any plans to upgrade the agents? Right now, their API is very bare-bones. You can't check if they've currently stopped, acceleration and deacceleration is the same thing, etc.
- Are there any plans to allow us to modify paths or program the pathfinding in any way? Right now agents will always cut any corner as close as possible. Having them move in different ways requires doing a bunch of navmesh raycasts, and losing the current path in the process. If you have something like a patrolling guard, you want it to go down the center of a corridor, not hug a wall!
- A huge lack in the current system is the inability to raycast against the navmesh. I'm not talking about the NavMesh' linecasts, I'm talking about "does this ray intersect the navmesh surface". That's very neccessary for things like "if I spawn some loot here, will the player be able to reach it" or "If the player jumps 2 meters in the forward direction, will they end up over a navmesh?". I've hacked that out by extracting the navmesh triangulation on build and storing it in a mesh, but it'd be nice to have this as a proper feature.

 

I started from a fresh project and I'm now getting 12ms non async with some GC, well below the 100ms so it's a project corrutopn (again, seems to be a new 5.5 feature) but still, this is the same as a full scene rebuild so I thought rebuild occurs scenewide even if a new source affects just a tile, but extending my test to much larger objects and changes that spike at 36ms I can see how efficient your system is - well done (and thanks for thinking ahead of us

Regardless of update speed, full scene baking is now BLAZING FAST!
Is nice

 

Yes - a surface is required for each type of agent. The NavMeshSurface component has a drop-down where you select which agent type to bake for. Also - agents have a type, and an agent of one type cannot use surfaces of other types.

Yes it's planned. But i can only guess when it'll be dome. Generally we are going for a low-level/high-level split of the API - and we expect to rewrite the NavMeshAgent (maybe not 100% match ) - in C# and then open the source for it). For the latter comment on raycast - i guess most people use physics raycasts for this - esp. considering visibility from camera, walls etc. - but it's noted.

 

On mcd we used NavMesh.SamplePosition with something like this:

Code (CSharp):

1. var hit;
2. var path;
3. bool reach
4. if (NavMesh.SamplePosition(lootPosition, out hit, 10, mask) && NavMesh.CalculatePath(hit.position, playerPosition, mask, path))
5. {
6.      if (path.status == NavMeshPathStatus.PathComplete) reach = true;
7. }
8.  

 

@Jakob_Unity It would be neat to have weight volumes that change the navmesh weight inside them.
This way we can transfer some of the AI decision to the navmesh like in the following RTS scenario :
The enemy convoy was destroyed by our artillery, the computer internally creates volume of high weight around the destruction area and the new convoy it's now sending avoid that area. The volume weight decreases slowly through time to simulate AI memory fading. If the computer created a long range radar then the volume moves with the threats and the weight remain the same.

 

Is that something other than using areas and setting area cost dynamically ?
Otherwise I suggest using that, in combination with NavMeshModifierVolume or NavMeshModifiers for moving area types.

 

ModifierVolumes are great but they don't allow to set the weight directly so I wonder if you could change this part of the cost weighting to be an int instead of 5 bit zones.

UpdateNavMeshDataAsync doesn't accept modifier input and mods don't affect the navmesh as is - how do I get that working?

 

It seems the new implementation is different from before for angular speed of nav agent. The rotation is even slow with a high angular speed. How can I make the rotate of nav agent faster?

 

@laurentlavigne our use case needs a method that will allow us to get a list of all the border line segments or edges of the navmesh, plus that 'segement normal' so that we can automatically generate cover positions, and perform rich AI decisions, is this possible?

(and if it is, would love a small example how please, we would use this at editor time to make a nice octree of edges for runtime query and at editor time for creating some things)

 

I'm looking at the docs, and I noticed a thing that really rubs me the wrong way:

That's really arrogant! The Unity community is making very many, very different games. For most of them, what you're saying is true, but there will be instances where creating the polygons will give better results for the user.

I'm going to go out on a limb here and guess that exposing the data structure that defines a navmesh and letting us create one would not be very hard, nor much work. If we mess it up and make a bad/slow navmesh, that's our problem. Let us decide what's best for our game!

Allowing us to directly read, modify and set the navmesh polygons would allow for a lot of interesting post-processing options. We'd also be able to create great tools and solutions for the Asset Store based on the navmesh.

The biggest problem the current solution has, in my opinion, is that it's so damned closed off, so doing anything that wasn't though of when it was made is near-impossible. Allowing us to decide what geometry to use is a big step up, yes, but allowing us to actually edit the mesh would be even more significant.

 

You're doing this offline for cover? Don't bother with topology because you'd have to produce the border normals yourself. Simply sample pairs on the navmesh and Navmesh.Raycast those pairs, then you add a tag in the center of each nav triangle or add a zone volume with N,S,E,W "cover" zone.

 

I'm just not familiar enough to know what you mean. With my old approach I knew precisely how big the wall is, and could get a position along it in cover. I'm not sure how I would know how "wide" my cover was with this approach... or how high.

 

Do you have any plans of implement a GOOD local avoidance for the navmesh agents. ? ( the actual "local avoidance" simply does not work.. the agents gets confused / push others ) or a way to get the navmesh path gets afected by other agents inside the path. ( like carve obstacles do ) .. so implement some good solution to avoid collision between agents.

 

Plan is to eventually make it pluggable - so you can replace it with your favourite avoidance code. But that's not really related to the current preview.

 

Are you planning on modifying the polygons on the fly - i.e. when path-requests are being processed and agents are moving ?

 

I personally prefer as much lower level access as can be allowed. As individual coders, control over and complete lucidity of our entire solution gives us superior flexibility to those working on teams. However, in this case, since the system is meant to function for every user from the dilettante to the guru, I believe their choice makes sense. Giving them the freedom to alter the precise format of the navigation data ensures a stable, efficient module can be developed. Linking pre-generated polygons can give more "natural" pathfinding results. You can achieve similar results by creating a waypoint graph and using that as the method for choosing nav targets(like sidewalk or street behavior ).

Personally, I would like to see these nav features added as soon as possible. Once the system has been developed though, I hope Unity does not leave it as is. When the core nav system no longer is at risk of requiring significant changes, I hope Unity will consider unlocking some lower level functionality (which sounds like is the ultimate plan based on previous posts). The current features seem to provide enough flexibility to creatively solve problems in the meantime,. So far, I've even been able to even create vehicles with seamless navigation thanks to the auto-update position feature on the off-mesh links.

 

my project is literally waiting for this new navmesh features

... well, iam not waiting now that its like usable