Excluding areas in a Recast graph

I’m only using maybe a third of my terrain effectively as walkable area. The rest is only used for “visual” purposes.
Is there a way to exclude the unwanted areas from the terrain with the Recast graph?

Thanks.

Hi

You can exclude layers from being included in the calculation in the recast graph settings, take a look at the ‘mask’ variable.
You can also make objects that are included in the calculation to become unwalkable by attaching a RecastMeshObj component and setting the ‘area’ field to Unwalkable (or -1 if you have an older version).

Excluding layers won’t help on the terrain, that’s just one huge object. Won’t it affect search performance if there are lots of regions which are never used?

Hi

It will not affect performance in any major way. It will mostly just take up a small amount of memory.
If you are using navmesh cuts which you move around or do any other graph updates, having lots of unused regions can slow down graph updates a bit since it will have to recalculate some information even for the nodes that are not used.

Thanks Aron.

I’m using a LOT of rocks and the majority of those shall not be walkable. Just to make sure, adding a RecastMeshObj component to all of them to set them to “Unwalkable” and ticking OFF “Dynamic” will not cost anything at runtime, right?

Hi

No, that will not cost anything at runtime (as long as you are not updating the graph, though even then the difference should be negligible or possibly it will slightly improve performance).

I have added a RecastMeshObj component to some of the rock objects that I want to be unwalkable, but it still creates regions on their surfaces. Any idea what could be wrong there? I set it to Unwalkable Surface and disabled Dynamic.
On the Recast graph I enabled Rasterize Colliders and disabled Rasterize Meshes.

Note: The rock has a collider on one of its LODs. On that object I added the RecastMeshObj.

Hi Aron, did you see the last reply?

Hi

Yes. I am not sure why that is happening. Hm… It is possible that the code for supporting recast mesh obj on colliders is only in my dev version and not in the released version. In the released version it might only work when you have rasterize meshes enabled and rasterize colliders disabled. However I think I released it some time ago it might be worth a try to see if that changes anything. I cannot check it myself right now unfortunately as I am not at home and I will be away for a few days.

Dev version == Beta?
The beta seems to be the same version as the release version.

Please let me know when you’re back and verified that the code is in the release.
Thanks!

Hi

Dev != Beta. Beta is released. The dev version is my internal version I am working on.

It seems it is not in the released version. However I think this should fix it for you:
In the RecastGraph class, find the CollectColliderMeshes method and right before this line

ExtraMesh emesh = RasterizeCollider(col);

add

if (col.GetComponent<RecastMeshObj>() != null) continue;

I have not tested this myself, but I think that should make it work properly with colliders.

Maybe I’m doing it wrong… but I have a terrain with a lot of mountains and it’s getting loaded with a bunch of mesh that I don’t want to be walkable.

image

So I made a large box and added a RecastMeshObj component to it, and set it to “Unwalkable”, and then unchecked “Dynamic”. I placed it like this:

However, after regenerating the navmesh, the box didn’t block any of the navmesh that I had intended to block. It did cut a seam through the navmesh though.

image

Is there something else I need to do to make it restrict the navmesh for large areas?

Hi

In the beta version, colliders are solid and will work as you expect. In the non-beta it doesn’t know that colliders are solid, and thus it only rasterizes their shells.

See A* Pathfinding Project

I’m using 4.3.61 (dated November 09, 2022)… I thought that was the beta… Is there another beta that I’m not aware of?

Ah. No that is the beta.

Probably you have rasterize meshes enabled in the recast graph settings. In that case it will only rasterize all the geometry, not colliders. Geometry is just a collection of triangles and there is no concept of inside or outside e.g. a box. You can check rasterize colliders if you want the desired behavior.

Or you can check the solid checkbox on the RecastMeshObj component.

I have rasterize meshes disabled in the recast graph settings. It has always been disabled. I already had solid checked on the RecastMeshObj component. I tested with and without this solid setting and it didn’t make a difference.

At your suggestion, I put a collider on the RenderMeshObj and checked “rasterize colliders” in the recast graph options. I set the layer of the cube to a layer I named “NavmeshBlocker” and I tested with the recast graph’s layermask including the NavmeshBlocker layer and excluding it.

The result is still the same as pictured above. I just can’t seem to find an easy way to trim the recast-graph’s walkable area. I suspect there is a way to do it, because I’m guessing it’s common for devs to limit the scanned navmesh area in some way.

Hi

I tried to replicate this, and I actually found a bug which I think is what is affecting you.
If the box is partially outside the graph on the y-axis, then it will not be treated as solid.

I have written a fix for this, and it will be included in the next update.

But in the meantime, to work around the issue: make sure the box is completely inside the graph’s bounding box.

(Sorry for the necropost)

Has this been developed on at all? It’d be a hell of a lot more manageable to be able to include a layer in the cast, but mark it as unwalkable so that it blocks the navmesh from going through it (for things like walls, props, etc) but doesn’t generate navmesh on top of it. While we can add an object to it, it feels a little odd to use layers for one thing but not another and I think recast would really benefit from an unwalkable layers mask alongside the main recast mask.

No. Currently you still have to attach the RecastMeshObj. I’m planning on adding some layer based tooling, though.

1 Like