I have a scene with a recast graph with tiles activated.
I tried out the new cool feature RelevantGraphSurface. I placed a empty gameobject in the scene and added a RelevantGraphSurface Script to it. I adjusted MaxRange so the gizmo lines go through my recast navmesh ground floor.
I chose “only for completely inside tile” for the surface mode and pressed scan -> The progress bar ran but nothing happened, all recast tiles are still in the scene. Also the ones, which are seperated from the ground floor (on the roof of skyscraper buildings e.g.).
If I choose “Require for all” for the surface mode, only one tile with the RelevantGraphSurface object inside remains. The other tiles vanish.
If I switch off tiles, “only for completely inside tile” works and all the ground tiles remain in the scene. The rest of the recast graph which is not on the ground plane, vanishes.
Actually I believe it is working as expected. The behaviour can be a bit counter-intuitive at times for technical reasons.
Quoting from documentation
Require every region to have a RelevantGraphSurface component inside it.
A RelevantGraphSurface component placed in the scene specifies that the navmesh region it is inside should be included in the navmesh.
If this is set to OnlyForCompletelyInsideTile a navmesh region is included in the navmesh if it has a RelevantGraphSurface inside it, or if it is adjacent to a tile border. This can leave some small regions which you didn’t want to have included because they are adjacent to tile borders, but it removes the need to place a component in every single tile, which can be tedious (see below).
If this is set to RequireForAll a navmesh region is included only if it has a RelevantGraphSurface inside it. Note that even though the navmesh looks continous between tiles, the tiles are computed individually and therefore you need a RelevantGraphSurface component for each region and for each tile.
So probably all your surfaces that you want removed, are adjacent to a tile border, and thus the connectivity of that surface cannot be determined fully at scan time.
I do plan to add an option to make a RelevantGraphSurface component remove the specified region from the navmesh instead of making sure it stays in the navmesh.
I have a scene with a terrain and a skyscraper object. After scanning the scene with the A* tool, the ground has a navmesh (color #1) and the roof of the skyscraper has a navmesh (color #2). The navmeshes aren’t connected. I checked that by switching off the skycraper. There is a ground navmesh and a second navmesh on the place where the roof of the skyscraper was afterwards : no connection between them.
If I don’t use tiles, everything works: everywhere where the RelevantGraphSurface object is, the navmesh part will be preserved. Everywhere else it is removed.
If I use tiles, the RelevantGraphSurface objects seem to be ignored.
In my opinion it would also be a good idea to not only check if a game object has a “RelevantGraphSurface” component attached to it but also to check, if this game object and its “RelevantGraphSurface” component are enabled. Users are then able to fine adjust the removed navmesh parts.
The ground navmesh seems to always be preserved. Even if the scene has a RelevantGraphSurface game object which doesn’t touch the ground navmesh.
And definitely there seems to be a connection with my problem and the “use tiles / don’t use tiles” option.
Can I send you an example scene? I cant find any email contact address.
Check where the tile seams are. If you view the navmesh from above (and you have Recast Graph -> Show Mesh Outline enabled) you should clearly see a grid like pattern.
Any region which is adjacent to another tile cannot be removed since when generating the tile, it has no idea about how the other tiles look.
the ground mesh and the roof top mesh aren’t connected and therefore not adjacent.
Can I send you a sample scene? You can see there that it doesn’t work if “use tiles” is activated and that it does work (to a certain point but not on every area) with “don’t use tiles” mode.
The meshes are colored with different colors which should also be an indicator, that the meshes aren’t adjacent.
Here are two pictures. The green cube has no RelevantGraphSurface component on it. The red cube has one on it (where the sphere is). The only difference between the two screenshots is, that screenshot 1 was made with “use tiles”, screenshot 2 was made with “don’t use tiles” :
Use tiles : both cubes have surfaces on the top. Only the red one has the Relevant… component on it. Also the ground has no RelevantGraphSurface on it, but is still there.
Don’t use tiles: The green cube seems to look right: no surface on it. The red cubes surface is preserved on the top: right. The ground plane still has a recast surface but no RelevantGraphSurface component on it: wrong.
I expected that both modes should produce the same result. But the results differ. In both modes the ground plane is always there. Is that intendet ?
Hm … if you think the behaviour I showed with the screenshots is normal, than maybe I completely misunderstood what tiles are. I thought, that tiles are not only in x-z but also in y direction cause it’s possible to have multiple regions in the y axis.
Tiles are only XZ. The scanned world is divided into chunks which are tileSize*tileSize large (in voxels, the unit used for rasterization, named cellSize in the editor).
So a tile may contain any number of layers.
Your first screenshot for example seem to be made up of 5 times 5 tiles.
You mean that navmesh areas which are on different Y axes and seem to be not connected through vertices (also have different colors) nevertheless can be adjacent ?
Hm… What can I do to remove the “roof top” navmesh areas on top of the cubes in my pictures above while using tiles then? I have to use tiles in my final scene cause the number of vertices in the scene is very high.
