Whole World Navigable seems to disable navigation altogether

There’s a toggle in the Engine → Navigation System section of Project Settings for “Whole World Navigable” which purports to generate navmeshes everywhere, rather than just within bounds volumes.

As far as I can tell, though, this just prevents any navigation data from being created. As a simple reproducer:

  1. Create a new level with the simple BSP floor template,
  2. Add a pawn controlled by an AIController
  3. Add some simple OnRMBDown logic to the pawn to issue a SimpleMoveTo targeting the mouse (trace from mouse, find the first navmesh in the project, project to that navmesh)
  4. Create a navmesh bounds volume and a recastnavmesh object.
  5. Scale the bounds to fully enclose the default floor, leaving a little extra room above for pathing height
  6. Play, and verify that things work as expected.
  7. Open Project Settings, enable “Whole World Navigable”
  8. Delete the navmesh and bounds
  9. Re-test, observe the AI repeatedly saying the target point isn’t on the navmesh (and nowhere near)

Note: when you enable whole world navigable, and delete the navmesh from the scene outliner, the next time you run PIE you’ll get a new navmesh object, sequentially named. If you toss a breakpoint in the blueprint debugger to check what’s being found by the “first navmesh” query mentioned above, you’ll see it’s that mesh.

I’ve also tried setting bRebuildAtRuntime=True in DefaultEngine – no difference.

Here’s a quick screenshot of the goal point and vislog, just to confirm the tracing isn’t the problem:

4929-goallocation.png

I’m not certain if I’m just missing a critical step here, or if whole world navigable is just not yet ready. Anybody got any experience making it work?

Another interesting find: If you pop open editor settings, head to level editing → misc, and disable “update navigation automatically” you will never build navigation data again.

Set up a simple scene with a navmesh bound, hit p to render it, see that it’s green and pretty. Move it. See that it rebuilds and updates.

Switch off that setting. Move the navmesh bounds, note that it does not update. Ok, that’s what we wanted. Hit Build. No update. Hit Build → Build Paths. No update. Enable rebuild at runtime for navmeshes, hit play, no update.

It’s looking to me like somewhere along the line things other than editor autobuilds of navmesh data are getting sad – off to visual studio to find out where.

Haven’t tracked down why yet, but tidbit:

Stick a breakpoint on RecastNavMeshGenerator.cpp:1985 @ 4.1 (start of FRecastTileGenerator::GenerateTile()). If you delete all the navmeshes and bounds from the level, add a new bound, hit build – breakpoint won’t trigger, mesh won’t build. Re-enable the editor automatically building navmeshes, breakpoint trips. Subsequent calls to build will again trip that breakpoint, but disabling the editor setting will prevent those builds from actually taking effect. The editor briefly shows changes (move the bounds, build, observe the red where there was green before) but on PIE it reverts to the last build triggered by the editor’s automatic process.

Ok, traced this a little bit – at least in PIE the code path followed for launch-time navmesh generation is the same as the one followed for editor autoupdate – NavigationSystem.cpp:468@ 4.1 – a call to OnWorldInitDone with bNavigationAutoUpdateEnabled as the deciding factor in whether or not navigation meshes get built (this boolean is toggled by the editor settings checkbox)

Doesn’t address the main question of whole world navigable, though. On to tracing that.

Hey there. Have you been able to make any progress yet ? I’ve just spend the whole day trying to figure out why my Navigation isn’t working correctly and came to exactly the same situation as you. I would like to help if you need it ? Let me know. Cheers. A

I haven’t touched this in a while – after a bit of code reading I figured I wasn’t going to find a quick fix. The strategy I wound up going with is a bunch of navigation volumes, which seems to do the trick. They rebuild at runtime just fine too, so I would imagine you could do some shenanigans with moving a pool of them around as necessary, but I have’t gotten that far myself.

The problem I have is I want the whole level to be navigable without a “floor” box present, thus I’m stuck here. I’ll scratch around in the engine and see what i can find.

Looks like a bug to me :wink: Filed in as TTP#337622. Will have it fixed soonish. 4.3 will have a fix for sure. For now just use bounding volumes, since that’s what’s being used internally and is guaranteed to work.

Cheers,

–mieszko

That would be great ! Thank you.