Recast NavMesh Crowd not properly parenting

I have been having an odd issue when playing with AR where crowd agents somehow are still tracked in scene, but don’t remain in relation to their recast navmesh if its XR anchor’s position is updated / bumped / otherwise changes. The end result is agents will sink into the terrain, or end up hovering above. I don’t know if this is a bug (AKA they are not respecting their parent) or just poor understanding of the setup on my part.

I shot this video. You can see some cube agents I added in start to sink in @ 50 seconds, by 1:16 they are all still moving correctly, but sinking fast under the terrain. By around 2:20 they are wandering around under the base apron for the map.

https://youtu.be/K_p4KiDoZW4

There are a bit too many classes to PG my code, but the Recast functionality is still fairly vanilla. So, if you open up this crowd example from the playground and change the Y value of the navMesh you can recreate it without AR.

My question is, how do I get agents to stay attached to their navmesh or any other common parent if its position changes? I tried a few things to update their transforms, but even simple solutions like parenting them messes up the crowd agents system and they can end up half way across the room moving around on my stovetop.

It’s hard to know what’s going on without seeing your code, but from what I can tell about nav meshes, they’re not movable after they’ve been created. If the static meshes used to generate the nav mesh are moved, then the nav mesh needs to be rebuilt.

@Cedric can probably say more about this.

As for the moving the debug nav mesh in the playground …that’s not actually moving the nav mesh :slight_smile: The debug mesh gets created from the current nav mesh only to visualize it. It does not update the nav mesh when it gets moved.

@docEdub is right, if meshes change, then you have to recreate the navmesh.
This said, in your video, I don’t feel like the mesh is moving. Only the camera does. So, the navmesh should be ok. in your app, do you move the terrain mesh ?

1 Like

It does not move intentionally, everything should be glued to the surface with an XRAnchor. But, from what I can tell, every once in a while the AR system updates (or temp loses track) of the anchor point that the terrain mesh is fixed to. This cause the terrain mesh to slide a bit, slightly changing position in the real-world. Not enough to visually notice when its happening, but enough to see units using the navmesh slowly end up visually stuck in the terrain mesh, floating ever higher above it, or as in the video, sinking down below it

So, for whatever reason the navmesh must be missing updates, or updates at different frequency, or there is a rounding error somewhere in tracking, or something. The effect seems cumulative, and is somehow related to XR anchors as I can really slow its progression with a VERY easy to track surface - a $9 Target shower curtain with a non-repeating, high contrast, random pattern VS. a hard to track surface - a clean & featureless table like what was used in the video I shot.

However, the few people I have put in front of the app keep trying to clean off a surface / table to use AR. Sadly, that is awful for tracking as you lose any reference points. But, it does seem to be a natural behavior, so not something we can easily break hundred (or fingers crossed thousands / millions) of users from doing. That means anchors are going to slide.

I worry about having to regen the nav mesh on the fly as its intensive to do, especially on a phone running AR which is already taxed. Is there no real option to parent / reuse that navmesh and just update its transform?

I can git the code tonight.

This is my temp solution. It helps tremendously, but does not fully cure the issue. Sadly, mailing everyone a shower curtain to play a game is not practical.

Which transform is changed over time? Is it the terrain mesh one?
You can you add all crowd agent transform as child of the terrain mesh. So if it moves, for any reason, agent will as well.
The goal here is to parent everything to the node that has its position changing because of XR.