Navmesh generation depends on camera location but shouldn't

I’ve simplified my original navmesh issue to the following:

I’ve got a flat voxel world, a navmesh that covers the entire map and I’ve got runtime generation set to static and not using any navmesh invokers (also turned the navmesh invokers setting off in project settings).

While in the editor (in selection mode), moving the editor’s camera around updates the navmesh, and the navmesh generated depends entirely on where the editor’s camera is. When I hit play, the last navmesh generated from moving around in the editor becomes the game’s navmesh, which usually involves some areas of the flat map being missing.

I’m wondering why navmesh generation would be tied to the editor’s camera?

The more complicated setup that my actual game requires has the following slightly different issue:

My actual game setup requires some characters as navmesh invokers, dynamic runtime generation and the use invokers for navmesh setting checked in project settings.

With this setup, the navmesh invokers (which are controlled RTS style with select and move mouse controls) do have an influence on the dynamically generated navmesh, but the in game camera is now a large deciding factor in where navmesh is generated. If I zoom my camera in close, some navmesh is generated in a radius around the camera, but some of the navmesh invoker’s nav area is cut off aroudn the edge of the camera radius… And then if I move the navmesh invoker characters, their navmesh area is only destroyed, never re-created unless they are close to the top down camera that is not linked to them.

I’ve looked everywhere in navmesh details, recast navmesh details, project navmesh settings, invoker details and the camera object to try to figure out why my camera has any influence over the navmesh generation, and I’ve watched a fair number of youtube tutorials and such to see if this issue ever comes up for others, and I’m coming up blank on all fronts

I’ve started a new basic project and build a simple version of my problem bit by bit and discovered that the spectator pawn causes the same issue in my new world with no explicit player pawn / camera.

Each of the following uses a flat voxel world with a navmesh bounds covering it all in simulation mode and navmesh viewer on. I have setup no camera, player controller or game mode (so I guess unreal is adding defaults when I press play).

My egg shaped pawn character in the scene is no more than the following with nothing in the event graph:

Egg shaped character

There are no suprises when I start with the following:

  • runtime generation == static
  • generate navigation only around navigation invokers == false

Next I update runtime geration to dynamic, and when I simulate, I can already see the spectator pawn which is spawned in by default is affecting the navmesh:

  • runtime generation == dynamic
  • generate navigation only around navigation invokers == false

And finally I get navigation invokers involved (of which my egg shaped pawn should be the only one), but now the navmesh is only generated in what looks like the areas around the navigation invoker and the spectator pawn overlap:

  • runtime generation == dynamic
  • generate navigation only around navigation invokers == true

I don’t understand why the spectator pawn is acting like a navigation invoker when it doesn’t have a navigation invoker component. It acts like one even before I set generation to use invokers…

But I’m thinking if I can figure out why this is happening, hopefully this’ll give me a clue as to how to fix the actual project which suffers from a similar issue but involving the camera instead of a spectator pawn. It feels like the cause of each should be similar.

Anyone have any ideas how to fix this?

…Further to the above, I’ve now created a basic camera pawn, and playing in regular viewport mode while showing navigation data with the command show Navigation.

My camera pawn is a subclass of Pawn, has nothing in the event graph and looks like so:

basic camera pawn

And this replicates my original issue fully. Now navmesh generation depends on where the camera is. It’s not just the view, zooming the camera out by just moving the camera pawn up and down by the transform.

In the following, I’m not using any control input, neither my egg shaped pawn or camera pawn have anything in their event graphs. I am just moving them around by manually adjusting their transforms… But the results are the same as when I move my camera and characters around using controlelr input in my actual project.

Also, settings are still as so:

  • runtime generation == dynamic
  • generate navigation only around navigation invokers == true

This is game start:

Here I’ve moved the camera pawn up a bit:

And moved it back down:

Now I’ve moved the egg pawn away from the camera:

And moved the camera closer to the egg pawn again:

I seem to have solved it well enough to move on at least.

On the nav invoker characters, I actaully need voxel plugin’s own invoker class VoxelSimpleInvoker (or one of the other voxel invokers depending on use case) to cause navmesh data to generate properly. The camera still causes it’s own navmesh data to be generated when it gets close to the ground which I’m still striggling to understand, but it’s no detremental to my game anymore.

I have discovered the voxel plugin docs actually explain the entire situation I’ve been facing perfectly, and the voxel invoker components are infact the given solution to all my issues, I just hadn’t managed to find the correct documentation previously.

I once again can’t find the doc that also explained my entire weird situation with the camera, but the start of the following doc explains the everything but the camera issue perfectly… The camera issue was caused by voxel plugin choosing the camera as a voxel invoker if no other voxel invoker can be found… Again, I can’t find the doc that states that now!

For future proofing, I’ve also accidently found the voxel plugin 2.0 doc that covers this:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.