I’m using Recast graphs in my game. I’m rasterizing colliders, but not meshes. In general, there is a list of Layers that should be included in the navmesh baking, so I have those layers chosen. However, there are a few exceptions where I want a certain object on a certain layer not to be included in the baking.
I know I could put those objects on another layer, but I already have a very specific layer usage in my game, and I don’t really have the option of adding a bunch of new layers that are effectively the same functionality as one of my existing layers, except that it gets excluded from baking.
I see I can include objects based on tags, but I can’t exclude them based on tags. Let’s say I have an object in the Default layer, and I want Default included in the bake. However, there’s one object on the Default layer I want to exclude from the bake. Is there any way to accomplish this?
I think at this point the only way to get precise baking is not to use any layers, and use a completely tag-based approach for what to include. But explicitly includes lots of tags feels much more sloppy and cumbersome than explicitly excluding a few objects. Do I have any other options?
Hey,
Layer setup for these physic exceptions should really be the way to go though.
Though I do think adding a recast ignore isn’t very hard.
Take a look at the RecastMeshGatherer script. I only took a few minutes to check up on it, and might be completely going in the wrong direction.
1 Like
Hi
You cannot explicitly ignore specific objects, though if you attach a RecastMeshObj component to it you can make the surface of the object unwalkable. However all objects which have a RecastMeshObj component will be automatically included in the scan regardless of their layer, so you can use that instead.
The specific issue I was running into here is trying to get the following sliding door to behave nicely with pathfinding. Here’s how the door should behave:
The door part slides up and down as agents approach it. In that sense, although the sliding door part has a physical collider on it, the agent should understand that it’s walkable, since the door will open by the time they get close to it.
Currently, though, because of the collider on the sliding section, the walkable strip through the door gets blocked.
Placing a RecastMeshObj on the sliding door doesn’t help. It seems the RecastMeshObj will only make the upper surface of an object walkable. It will still make the perimeter of the collider unwalkable.
Just to mess around with the code a bit, I tried inverting the “tag” logic in CollectColliderMeshes, such that a collider having a tag excludes instead of includes it from the filter. That ends up doing what I want. It would be nice if the graph formally supported two tag lists: One for including, and one for excluding.
That is, unless there’s another approach I can take to this.
Again, going purely based on layers is very difficult for my project, as I’m nearly out of layers. I don’t have enough remaining layers to create “*WithNavigation” versions of every layer that I don’t want to be scanned by the graph.
1 Like
Unless this messes with one of the other gameplay systems in your game, you could just put the door on Ignore Raycast layer. And exclude that in a*.
Yeah, that’s the tricky part. My game leans heavily on physics, with lots of special interactions between objects depending on their layers. So this door is already on a specific layer, which up until I added pathfinding was fine. Given the number of layers I have, and how few total layers are actually available, I was hoping to use tags to control the edge cases.
For now I’ll probably just leave my CollectColliderMeshes edit in place, which makes the tag list an exclusion list instead of an inclusion list, but it would be nice to see this as a formal feature in a future version, so that I can avoid maintaining edits of the AStar code.
Hi
I have added a mode to the RecastMeshObj now that makes an object be completely ignored.
This will be included in the next beta version update.
2 Likes
That sounds perfect. Thanks. 
