Recast graph - exclude ground under houses

We’ve got a big city that’s essentially one big plane for the “streets” and a bunch of cubes that mark houses. I want to build a recast graph based on the streets. For somewhat large houses, though, a graph shows up inside of them, as the ground in there is large enough to allow a piece of the recast graph to show up.

Now, I can fix this by setting a really huge region size (4000 manages to exclude all the houses), but that seems hacky. Is there some better way to say “don’t consider anything inside of this box as a walkable surface”?

RecastMeshObj with Area type set to “Unwalkable Surface” prevents graphs from showing up on the roofs, but not inside the houses. I could create a plane on the floor and then later delete it, but I want to check if there’s something built-in I’m missing.

Reply to self: Setting a large Walkable Height value fixes this. That prevents underpasses, but this solution is very workable.

Have you tried putting a box collider marked as unwalkable inside the house where the space is?

I haven’t. That would work, but we have a lot of houses, and I’d rather avoid the clutter. I’d also have to teach the level designer to place out the box colliders, and I kind of want moving houses around be minimal work, so the process for the designer is as smooth as possible.

The houses all have an editor script already, so I could make that script create and then destroy the box colliders when the recast bake happens. Or the script could simply hook into the build process itself and do something like what the RecastMeshObject is doing.

I was looking for a way to do this that’s a bit more lazy, since we’re prototyping and I don’t want to go too deep into coding up solutions. Having a large walkable height was exactly the lazy I need. Now my 2 meter tall npcs need 20 meters of space above them to walk, but it works for our use case.

Most reasonable solutions have been mentioned already, so I cannot add much. I would just want to add that I have an experimental branch where colliders (except mesh colliders) can be treated as solid instead of hollow as they are now. I could share this branch with you if you want, but I am not sure if it would solve your problem. It depends on if you have colliders on the boundings already.

This is probably the easiest solution.

@aron_granberg has that experimental feature (colliders treated as solid instead of hollow) been implemented in the current version, and if so how could I activate it during the scanning?

Also very interested in this. Would love to be able to set a box collider with a RecastMeshObj component set to “Unwalkable Surface” and that prevents any surface inside it from generating nav. Has this been included in the project?

@aron_granberg So is there a viable solution to this from that experimental branch? Since the app we’re devolping generates navmesh on user-generated content, we can’t really go the hand-authored approach. It would be ideal to be able to mark up some colliders as “solid”, but even having them all be solid would be a better solution than having them all be hollow. All of our user-generated navmesh is baked against collision.

@aron_granberg
I too am finding that I’m going to most likely need a feature like this for my game. I have expansive levels with complex geometry and there are lots of objects with cutouts underneath them. Are there any updates on whether this feature was viable to implement? If not, what was keeping it from working?

Hi

Yes! I am in the process of translating the recast code to use burst. In the process I’m also implementing this feature.
It will be possible to mark all convex colliders and meshes as solid.

2 Likes

Thank you for the response! Glad to hear it.

Hey, any updates on this one? We also really need it for our game :slight_smile: Thanks!

@Shosanna

Yes. In the latest beta all convex colliders will be solid, i.e. no navmesh will be generated inside them.

3 Likes

Thanks, I will try that!

1 Like