State of AI in 4.6.1 - 4.7 [XYZ navigation]

Ok my game is in space and it is heavily dependent on XYZ navigation. On one livestream the lead C++ dev (don’t quote me on that) , said it is possible someone to write their own 3D navigation code, BUT that it will not be coming to UE4 anytime soon.

So what should I do if I want my AI to be able to navigate a complex 3D maze , or just chase the player in the complex 3d maze.


I wonder if you could have one navigation mesh for horizontal and another for vertical. If it is possible to align a Navy mesh at a 90 degree incline then you could probably work it out.

Alternatively you could work your own pathfinding solution out but it is going to take a serious amount of effort.

Maybe one more option would combine both. Create a series of stacked nav meshes and then use blueprint logic to manage transitions from one navesh plane to another.

Stacking NavMeshes will not work because the OP wants true 3D navigation and NavMesh is a 2D solution. Yes it works in a 3d space, but it’s not a 3d problem. My recommendation is to learn how NavMesh solves pathing and extend that into 3d by creating your own custom solution. Either way, you’re going to need to make your own pathfinding alg for now. And it might take some work, but you could leverage UE4 in certain ways…

My advice: Look up Portal Based Culling. It does scene culling by grouping scene geometry into rooms and hallways, each of which are connected by “portals”. Portals(Doors, archways, exits, entrances, etcs) in this case are simply intersections between bounding boxes (volumes). Each volume represents a room or hallway. Each room or hallway contains scene geometry. To briefly explain: If you are in a hall way, and the game tries to determine what you can see, it will assume you can see everything in that hallway (pending frustum culling). It will then cast rays to each portal and if the ray intersects only that portal it is implied that you can see beyond it into the next room or hallway, resulting in all of its objects being potentially visible. If your back is turned to a portal, or the portal is completely behind some occluder (the ray intersected something else), then you can’t see what’s in the next room so the renderer knows to ignore all objects.

The data structure used to create a portal scene hierarchy is a graph of nodes with each transition being the portals themselves, and each node being the area. This is perfect for path finding and in fact this is how NavMesh does it, except it uses planes (triangles) to represent areas, with the edge of the triangle being the transition. Same solution, but less complex.

You can easily use something like this for 3d navigation.

If you want to move toward an object…

  1. Determine which room or hallway the object is in.
  2. Do a graph traversal to determine which rooms and hallways you need to travel through to get there. (You can use a path finding algorithm of your choice for this.)
  3. Move toward each “portal” until you are in the same room or hallway as the object, otherwise move directly toward the object if you can see it.

How you create these rooms, hallways and portals is up to you. The first thing I’d try to do is leverage UE4s existing volume objects, and figure out how to extrapolate planes that represent the intersections between them at load time. These planes would be your portals. I would then construct my maze out of actors, with each actor being a piece of geometry that has your new custom navigation volume attached to it. That way you can create your maze either manually or dynamically by attaching these actors together. The volumes would then intersect, and from these intersections you’d create your portals.

I hope it helps.

Wow thanks , I think I will not be going that way. It will take a huge portion of my dev time and my gameplay is not based around the player being chased . It will be an improvement but it will not be of great importance.

PS: If I decide to give it a shot do you think Blueprints will be able to handle this ?

Out of interest what is the difference between XYZ Navigation and say the Butterfly blueprint AI in UE4’s demo? I have been modifying the Butterfly template and although I’m finding it difficult to make it fly randomly the AI does seem to navigate in XYZ?

I’m a newbie but to me it seems that all a basic setup would require is forward movement with random rotations (X,Y,Z) and a collision trigger that upon contact with a surface forces a rotation avoiding objects ahead by changing direction. This is obviously for more of a roaming AI however triggers could also be used to GET nearby objects coordinates and move the AI towards the same coordinates when the trigger is in range.