Hi all, this is my first post. I’ve been using unity for a few weeks and have only been using AStar for a week or two so I’m still getting to grips with it all.
I’ve implemented AStar and RVO simulation successfully into my WIP RTS game. Buildings can be placed anywhere, and are integrated into the navmesh using Navmesh cut (which is super fast and works fine), and a simple RVOSquareCollider. The problem is that when I place a building, the game locks for about half a second while the RVO collider is added to the RVO sim, and even worse, the more buildings I place the longer it takes; placing the 18th building took 3 seconds! So it would seem like it is recalculating all the existing colliders each time. I’ve isolated different parts of the code and it is definately when the building activates it’s RVO collider component that the game locks.
So the question is, does adding RVO colliders during runtime usually take this long, or am I not doing it the right way?
Really, 3 seconds??
They do recalculate all obstacles each time, it is needed because it internally builds a lookup tree of everything to be able to do local avoidance fast… but 3 seconds for only 184 edges… I did a small test for 25 square obstacles it was still under 0.08 seconds (though this is still quite slow I must confess). I should do some work on implementing an R tree or something, that would also avoid the need to recompute everything at every update.
Yup, 3 seconds on an i7 cpu. The building gameobject simply has the pre made RVOSquareObstacle script attached to it which activates when the building is placed. Is this how you do yours or is it added entirely in one script?
Well, first off I’m not sure why you need both a RVO collider AND Navmesh cut
…
If you could explain what your trying to do in further detail I bet we could make just the Navmesh work !!
I put the RVO collider in just to make sure my units don’t walk through walls; the RVO sim sometimes pushes units out of the navmesh boundaries when there are lots of them, which is why i added it. The aim is to have buildings with walkable interiors so it needs to be accurate, and if i were to get rid of the colliders id need to be sure the RVO agents wouldn’t go bumbling through walls. You do have a point though
I agree with Tateo and I have exactly the same problem. Adding RVO colliders is extremely slow and the cost seems to be exponential when the number of colliders increase. And of course, the number of RVOSquareObstacle is added to the already existing obstacles created by RVONavmesh.
Personally I’ve decided to not use RVOObstacle with my dynamic obstacles and I rely on pathfinding graph update and physic colliders to prevent my agents to enter an obstacle.
Using RVOObstacle give better result when there are many agents on bottlenecks, but the current performance issue prevents me from doing it.
