We are using recast graph for our game. Since we have units of multiple size I tried to add another recast with different stats (character radius/height)
Unfortunately it looks like navmeshcut cuts only the first recast. I’m using the TileHandlerHelper class but it looks like it’s linked to only one recast.
From there I don’t know what’s the best approach to take.
Should I not use another recast and handle multiple units size differently ?
Or should I modify TileHandler/Helper so it can support multiple recast ?
Yeah. Sorry. The TileHandlerHelper in the currently released version only supports one recast graph. I have a modified version in a branch which supports setting which recast graph to use so that you can have multiple.
However it should be fairly straightforward for you to modify it to use a specified recast graph instead of just the first one.
We’ve also hit this same issue (wanting to use NavmeshCut to modify multiple recast graphs that we are using to support different sized creatures). Did the branch mentioned above that supports setting which recast graph to use in TileHandlerHelper ever make it into the main code base? If not, would it be possible to get a copy of the code?
If I was going to do this myself, I was thinking of just removing the check that destroys multiple TileHandlerHelpers and then adding a field that lets you select which graph to update. Then we’d just have multiple helpers each updating a different graph. Is this the best approach?
Additionally, to support the case we’re talking about here, it would be great if the NavmeshCut script supported getting the character radius from the target graph and factoring that into the cut so that different sized characters could avoid objects more accurately. Right now I’m assuming we’ll just have to set the cut sizes to accommodate the largest possible character, meaning that smaller characters will avoid the objects more carefully than they really need to.
I ended up fixing this - or at least I think I have. I modified TileHandlerHelper to find all recast graphs and then create a TileHandler for each and apply the cuts to each TileHandler. That seems to work.
Adding multiple TileHandlerHelpers looked like more work as that would mess with the logic where the cuts know when an update is required (multiple updates would be required, one for each TileHandlerHelper).
Hi. Bit of necroposting here, but I’m basically getting the same issue and have no idea how to properly modify the TileHandlerHelper to work with all the different recast graphs I have in the game in the same time.
All my current attempts failed miserably.
(I know how to modify to get all the graphs, but I think I have a hard time adaptating the rest)
(using 4.1.16)
Can one of you help ?
Thanks
Edit - one week after - : still failing, only the first graph get the updates. It was working perfectly before I updated to newest 1.16 (I was on 1.4 before)
The whole new system made of events and callback is probably better, but it’s a litteral nightmare for me to find a solution and I would really be glad if anyone can pinpoint me in the right direction.
I mean, isn’t that common to have multiple graphs on one scene and to need navmesh cuts for all of them ?
I just uploaded beta 4.1.19 which includes out of the box support for navmesh cutting on multiple graphs. You don’t even need the TileHandlerHelper component anymore.
Let me know if anything doesn’t work as it should.
Hi. I had tried some reloadinBounds and it was working not too badly with an enhanced tilehandlerhelper. So it was working fine, no lag or such when I moved a navmesh cut object and stuff updated properly whatever was the concerned recast graph.
But, although most of the new features works great, I’ve got a big issue with this newest 4.1.19 beta: after updating to this new version, when I move a navmesh cut gameobject ingame, whatever is the update time of navmesh (set in advanced settings of astar), as soon as the update happen, I will experience a slight, one demisecond freeze of the game.
So that freeze is clearly a big problem, it really feels like a lag caused by the whole recast graph (or maybe all of them) being updated, rather than just the close boundaries of the navmesh cut.
Yes, I was on 4.1.16.
So, to recap
4.1.16 -> Multiple Recast graphs (with hacked TileHandler) + any navmesh cut moved/enabled/disabled on runtime = no freeze when updating the graph/boundaries.
4.1.19 -> Multiple Recast graphs (no more TileHandler) + any navmesh cut moved/enabled/disabled on runtime = freeze for a demi second when updating the graph/boundaries.
Currently uploading, I’ll send it to you by pm in the next hour.
-to test the issue, simply start the scene and move a navmeshcut object, you should experience lag/mini freezes on doing so.
Includes 2 other issues that you might want to look at:
-navmesh cutting update in advanced apath settings sets back to 0 on runtime
-look at GetTerritoireForet gameobject on runtime, the RVO Navmesh walls isn’t completed
I downloaded the latest beta, but I don’t see any option in the Navmesh Cut component to choose which navmeshes to cut.
I have some obstacles in my graph that are dynamically instantiated, but I only want them to apply to certain Seekers. I figured I would make a different recast graph for them and use navmesh cut. Seems pretty simple. Is this the right way to do it, or is there a better way?
There is an option in the graph settings which allows you to enable or disable navmesh cutting for the whole graph. There is currently no option to apply some navmesh cuts to some graphs and others to another graph.
@Immudelki
Sorry for the long delay. I forgot about this thread.
I did track down a few issues.
Firstly. The RVONavmesh component was told to recalculate the graph boundaries once for every graph that was updated, so it was doing recalculating everything 4 times instead of just once.
Secondly, your tiles are very large, and the tile connection code wasn’t quite optimized for that. This is however not something that would have changed between 4.1.16 and 4.1.16.
Overall I managed to improve the performance by around 4x. It does still take about 100ms to move a navmesh cut on my computer though (or 70ms with the .net backend) which is quite a lot. I would recommend slightly smaller tile sizes to improve performance. I tried with a tile size of 512 and that brings the update time down to 30ms (of which half is the RVONavmesh component).
