Navmesh links on a moving object

Hi, first time contributing on Unity Beta package here. Love the progress on the navmesh system. The new Navmesh surface component is amazing and makes having a navmesh on a moving object possible. The navmesh links however do not move with the object, breaking the ability to navigate from one mesh to the next…

https://vimeo.com/196601199

Is there a better way to link up Nav Meshes so as to accommodate motion of the object?

1 Like

If you would like the NavMeshLink to follow the transform they’re associated with you need to explicitly enable the “Auto Update Position” on the link.

Please note that proper support for moving surfaces will require a new API for the navmesh instance - currently moving a navmesh surface at runtime is indistinguishable from teleporting it - and will confuse the users NavMeshAgents wrt. avoidance.

2 Likes

Well DUH Chris lol. This is all very exciting and in my defense I had just got off a 12 hour noc shift.

So, is there consideration for a way to bake the nav mesh based on a custom “up” vector rather then the y-up of the object?

Also will there be some ability to auto generate off mesh links between nav meshes like you could in a scene-baked navmesh?

Just place the surface on a separate GO - defining the up-vector you like - alternatively digging into the navmesh surface build code may give you an idea of how to extend or customize the surface for an arbitrary up-vector.

for auto-generated offmeshlinks: many users found that it was quite hard to tweak the results. We plan to replace it with a more flexible system.

I am procedurally building large voxel planets, subdivided by an octree. There will be some level of AI running all around the planet and some just spawned within render range. The noise from the planet is derived from a main layer of basically 2D noise by converting cartesian to longitude/latitude coordinates.

I have a few options that I am playing with for surface pathfinding:

  • Bake the 2D noise into a heightmap and navigate via the heightmap. This may end up being a quadtree that is built on demand. Possibly some issues with floating point precision and getting units to stick closely to the surface.
  • Navigate via the noise function directly
  • Real-time navmesh by chunk (set octree depth for navmesh creation)
  • Real-time navmesh surrounding each unit
  • Raycast chunk vertices in a separate thread using a custom raycast implementation

I would like to be able to use the new NavMesh system in a way that keeps my options open for integrating AI assets that use NavMesh.

I have a few questions/assumptions:

  1. The quadtree heightmap solution would probably let me scale the number of units up highest? Possible memory issues if too many chunks are active. Floating point precision issues (maybe solved by raycasting the found path to get an exact location). Can I provide a heightmap to NavMesh along with a custom function reference that allows it to also convert the heightmap to spherical coordinates?

  2. It seems like the new real-time NavMesh is voxelizing a mesh in real-time? It would sure be nice to be able to pass a function/override and allow the NavMesh to sample my signed distance field directly. This avoids the need to build N depth meshes for offscreen chunks while still allowing AI to navigate there.

  3. Is there a caching/sharing mechanism for the surrounding-each-unit navmesh? I would e.g. like the scout/pioneer AI to generate this while he explores and the other units to prefer these paths. Cached paths would be given a higher priority and this solution could scale up to many units. The scout/pioneer would drop point-of-interest beacons/markers.

  4. I should be able to use a NavMesh on a planet as long as it is subdivided enough that each chunk has a mostly uniform ‘up’? (i.e. larger planets would work, a single-mesh smaller planet would not) Just use the ‘average’ normal of the spherical coordinates as Up, correct?

For auto-generated links, it would be nice to be able to provide a ‘map’ mesh. Basically, use the bounds center point of each leaf chunk in a quad/octree to build a link mesh. When a NavMesh surface is built for a child of that GO, check its bounds center against the bounds center in the map mesh and the edges are your connections? This would also allow you to use the same pathfinding algorithm to traverse the map mesh as you do the navigation mesh?

It would be nice to be able to provide just a map mesh and a callback function – so the NavMesh system can request data for a chunk that it doesn’t have when it first needs it. Use the normal of the map vertices to define local Up. Then any terrain engine just needs to update the map mesh as new chunks become active and manage its own callback for feeding per-chunk data.

Ideally, there is some caching mechanism here (e.g. LRU dictionary of bounds center points) – maybe one additional callback that is called before the data callback, to allow the terrain to return a NavMeshSurface object directly? Or internal to NavMesh itself…

Quick rough demo of full on spherical pathfinding. Very sloppy with the off mesh links but it gets the job done.

https://vimeo.com/196926607

Yeah - the plane parallel assumption breaks down for high curvatures. the planet has to be “big enough” - in which case you don’t want a static baked navmesh for the whole planet - but rather a ‘sliding window’ around the region of interest (e.g. the protagonist).
reaking the p

For auto-generated links we imagine an annotation system where you paint the seeding of offmeshlinks - keeping that information next to the navmesh … but development hasn’t started yet - and unlikely to be done for 5.6

1 Like
  1. No custom heightmap support yet for position lookup - but definitely something we’d like to provide.
  2. That’s a great idea - we’d start more modest first : allowing heightmap in addition to mesh and primitives.
  3. There’s no per-unit caching - you can update each navmesh in separate volumes (box for now).
  4. Yes - keep in mind that by updating the navmesh locally around a moving point of interest might also work.
1 Like

@Jakob_Unity – thank you for the answers and insight into your line-of-thinking. The frequency of beta releases and consideration going into and communication around new features is very useful for a single developer trying to plan where his time ‘today’ is best spent.

On #3 – I was thinking more along the lines of having a NavMeshSurface attached to a chunk GO where the NavMesh is not baked real-time and is initially empty, but ‘completed’ JIT as the area around a POI/unit is analyzed – allowing those calculations to be shared by other entities/units that might use a similar route.

Hi, new Unity developer here. Trying to make a VR game where you play on a moving platform and can teleport around, all while moving through a landscape. Can someone confirm the latest beta would be able to support this? It seems all teleport solutions on the market require use of NavMesh, and with earlier version, the only way we got it working was to set it to static, but then the navmesh gets left behind while the platform and player moves away. Thanks!

Sounds like you out to get it to work as you can have the nav meshes auto update position as the platform moves… Traversing the nav mesh links when it’s moving can be sketchy tho…

K… so I’m missing something. How exactly do you designate the nav mesh agent type? It’s not a setting on the nav mesh agent. Is it just based on the radius of the agent? Thx.

There seems to be a problem with the beta - where the drop-down intended for agent type selection is missing from the agent inspector - fix is on its way (one or two betas away)

So will separate navmeshLinks need to be created for each type of agent and also be designated in the inspector? Or will there be an “any agent” designation? Thx

  • NavMeshLink – connects same or different navmesh surfaces for one agent type.

Is it possible to add a navmesh as a children of the player so when the player moves the navmesh moves with him? How can I do it? Can you show me an example?

Not as a child per se, but one of the example scenes has a nav mesh that is projected down from above the player, achieving the effect you want

Thank you! Where are the example scenes? In the 5.6 Beta version?

Here’s the github listed in the release notes…

https://github.com/Unity-Technologies/NavMeshComponents