how is the dynamic navmesh in production?

About to do the first pass AI, the open world is quite vast, early test are encouraging but by experience the corner cases bite you in the ass after you've spent copious time implementing and testing, don't really want to waste time on this.
Has anyone used in-built AI in production, with a dynamic environment?

 

We have a 170+ sq mile simulation of london with traffic and pedestrian AI, with many advanced interactions, capable of having 200+ active agents moving around in a small space without issues. Over a larger area, 1000s of active agents is possible (active meaning moving and thinking, not doing long distance out of sector logic)

EDIT: So basically, its as good as the work you put in! A pain in the ass though when it goes wrong!

 

I use it for a city-building game with dynamic road positions and it works. I think there was one issue with it sometimes not recalculating when placing a road, but it could be related to my own code, or the navmesh settings. And it was only when the road was a seperate island.

Also, it was WebGL at one point and there was no hitching when recalculating.

https://gfycat.com/gifs/detail/MeatyWideeyedBlackbuck

 

h

your cars dont care for lanes, this lack of control in the pathing seems typical of the unity navmesh but maybe there is directional zones now. if it doesnt exist you are better off making your own, uding vector flow.

EDIT: only nav links have directionality. Probably not worth the bother and besides yiu change the architecture of your city buulding game to India and this bug suddenly looks like an accurate representation of reality https://docs.unity3d.com/2017.3/Documentation/Manual/class-NavMeshLink.html

 

elaborate

 

They're not cars. They're people pushing delivery carts.

 

Well once you have a bunch of complex agents on a large terrain and a bug crops up, it is very very difficult to track what is causing it due to the already crazy nature of navmesh agents, and how many things can interact with them. Because of this, we find its actually better to not let the navmeshagent move the agent, but instead we do all the moving ourselves and instead just use the navmeshagent to query paths on the navmesh and essentially do A* queries. We then have a very in depth gizmo and handle drawing class which illustrates in the scene view what each agent is look at, moving to, thinking about, etc so that determining "buggy" navmesh behaviour from "unity is weird" navmesh behaviour is easier.

Still very difficult to get it dependable 100% of the time with PhysX being utilized a lot. Without too much physics interactions, the navmesh system is a breeze to integrate.

 

@Daemonhahn It seems to me that just using the navigation mesh drawer and physics debugger in combination with a custom gizmo that draws the agent's path, and other related details, would be more than sufficient. However, I'm sure you have good reasons for doing it in this roundabout way.