I have two questions about Navmeshes and Obstacles:
Is there a limit on how many obstacles you can have at once? That is, does it start affecting performance if you have too many of them?
As I understand it, an obstacle that is not moving can be set to carve a hole in a navmesh. Is that constantly updated (and therefore would need to keep an obstacle in place), or is there a way to ‘freeze’ the navmesh so that it doesn’t update? What I mean by that is, can you drop an obstacle in place, have it carve a hole, freeze the navmesh in some way, and then remove the obstacle without the hole disappearing?
Well, what I mean with #2 is, when you drop an obstacle on the navmesh it will carve a hole. When you move the obstacle, the hole fills back in. What I want to do is delete the obstacle WITHOUT the hole being filled back in. Basically, I want to see if I can prevent the navmesh from updating again after the initial hole is carved.
Maybe it might also help if I try to explain what I’m trying to do. I want to make a randomly-generated maze that navmesh agents can navigate. The problem with randomly generated maps is that (if I understand correctly) you can’t really generate the mesh on the fly after the level is constructed. I had an idea around this but didn’t know if it would work. What I wanted to do was just make one big, flat navmesh and carve out holes in it where all the walls will go, with the remaining space being the maze itself. The problem is, in a large maze (or even a small one in many cases), that would mean a LOT of obstacles being spawned, which would more than likely affect performance greatly. But if I could spawn the obstacles, let them carve the holes in the navmesh, freeze the navmesh somehow so that it won’t update anymore, and then delete all the obstacles, in THEORY it would leave behind a working navmesh of the maze.
If the obstacles don’t move there’s no recalculation. I’d say just leave them there. There’s no mechanism for keeping the navmesh while removing the carving obstacles - it will restore the original part(s).
Thats one thing that really annoys me with some devs. They dont even try, and say it will be sooooo big performance hit… Man this Unity’s navmesh thing is really well optimized, i tried with hundreds of soldiers, with NO performance impact. No difference in profiler. And as Jakob said, it will update only when necessery, it wasnt coded by amateurs. So check before you cry about performance, ok ? Cheers.
I wasn’t crying about performance. In the first post, I asked if it WOULD affect performance, and the first response was that it would. I was going off of what he said, that’s all. Perhaps try to be a bit more courteous and read the thread fully before posting derogatory comments please?
Also, I should point out that I can’t just “try”, because I would need cube obstacles which are only in Unity 5, and currently I have Unity 4, so before I spend $750 on the upgrade I wanted to see if it would even be possible to do.
I have Unity 4 Pro, which I’d have to completely uninstall in order to install Unity 5 Free, which would break all of my other projects. So no, it’s not an option.
I see what you’re getting at. You want more control over the navigation system as I do because it’s very lacking in that department. Aaron Granberg’s pathfinding project gives you that control but I think he stopped developing and distributing the free version. If it’s worth it to you, you should cough up the $100.
Yes, asset store is almost always nice option, but in his case, unitys navmesh is definitely sufficient. Imo bigger problem is navmesh baking system(very basic) and lack of control on how agents are moving. But in that case you can always just use your own moving system like I will do
I actually went ahead and upgraded to Unity 5, since I figure I’ll have to eventually anyway for future projects. Turns out that you really can have hundreds of obstacles carve up the navmesh and it seems processor-free so long as the obstacles never move.
The above is what the navmesh looked like when I made a single large navmesh and then carved it up based on a random map generator. It seems like it’s working fine.