NavMesh assumes
you have a floor.

Down is not a universal constant.

NavMesh is great, right up until your character stops agreeing that the ground is beneath it. It bakes surfaces you can stand on, which quietly bakes in the idea that there's a single "up". Spiders, climbers, fliers and swimmers all break that assumption immediately.

I could have hacked around it — multiple NavMeshes at different orientations, stitched together. People do. But it's a workaround for a model that just doesn't fit, so I wanted to build the thing that treats the world as a volume from the start.

The catch: a volume has vastly more places to be than a surface does. Making that practical at runtime, rather than merely correct, is where most of the actual work went.

A 3D grid instead of a navigation mesh.

The bake walks the volume as a 3D grid and asks Unity Physics, for every single voxel, "could the agent be here?" It is exactly as brute-force as it sounds, which is why it happens once at bake time and never again at runtime.

A voxel passes if there's room for the agent and it satisfies a maximum distance-from-wall. That second condition is the one that makes this useful rather than generic: a ceiling-crawler needs to stay stuck to surfaces, so the empty middle of a room should be unwalkable for it even though there's plenty of space there.

I built this for things that climb, not for things that fly. But the constraint is just a number, and turning it off should leave you with a grid full of open air — so a flier would probably fall out of it for free. I haven't tried. Now I want to.

A* running directly in 3D.

A* itself is the least interesting thing here — it's the same algorithm everyone knows. What makes it fast or slow is the open set. Sorting a list every iteration is the classic beginner move, so it's a hand-rolled binary min-heap instead, inside a Burst-compiled Job where managed collections aren't invited anyway.

Every voxel has 26 neighbours in 3D, not 4 or 6. All of them are searched, so an agent can cut a proper diagonal through a room instead of doing that unmistakable staircase shuffle.

Here's the heap. It's built on a NativeList so it can live inside a Burst job. Instead of swapping a node with its parent at every level, it slides a hole up or down and writes the node exactly once, when it finally lands.

[BurstCompile]
public static class MinHeap
{
    public static void Push(ref NativeList<PathNode> heap, in PathNode node)
    {
        int i = heap.Length;
        heap.Add(node);

        while (i > 0)
        {
            int parent = (i - 1) >> 1;
            if (heap[parent].total <= node.total)
                break;

            heap[i] = heap[parent];
            i = parent;
        }

        heap[i] = node;
    }

    public static PathNode Pop(ref NativeList<PathNode> heap)
    {
        PathNode root = heap[0];
        int last = heap.Length - 1;
        PathNode node = heap[last];
        heap.RemoveAt(last);

        if (last > 0)
        {
            int i = 0;
            int half = last >> 1;

            while (i < half)
            {
                int left = (i << 1) + 1;
                int right = left + 1;

                int smallest = (right < last && heap[right].total < heap[left].total)
                    ? right
                    : left;

                if (heap[smallest].total >= node.total)
                    break;

                heap[i] = heap[smallest];
                i = smallest;
            }

            heap[i] = node;
        }

        return root;
    }
}

No decrease-key: a cheaper route just pushes the node again, and the stale copy gets skipped when it's popped. Lazy, and faster for it.

Nobody should have to type coordinates.

A clever algorithm behind a wall of raw inspector fields is a clever algorithm nobody uses. The default Unity component view would have made you type the bake volume's bounds in as numbers, which is exactly the kind of thing that makes a designer quietly go back to NavMesh.

So the volume gets Scene-view handles you drag, snapped to voxel multiples so you can't accidentally author a half-voxel. Voxel size, wall distance and the bake button live in one dedicated window, and gizmos draw the walkable voxels so you can see what you baked.

Bake once. Not every reload.

Sampling a whole volume against physics is slow, and Unity reloads domains constantly. Doing that work again on every script recompile would have been an excellent way to make myself hate this tool, so the grid goes into a ScriptableObject asset.

The voxel size is saved next to the packed data, because packed bits are meaningless without knowing what scale they were packed at — and a silently mismatched voxel size produces paths that are wrong in ways that look almost right.

From a static navigation grid to a living navigation system.

The current system is designed around a baked navigation volume. The next step would be to make the navigation data more modular, reusable and responsive to changes in the environment.