Welcome! - New NavMesh Features Experimental Preview

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

 

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.

 

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.

 

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?

 

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.

 

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?

 

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

 

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

 

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.

 

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.

 

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