I have been using the free version of A* for a little while but just upgraded to the pro version as part of the Black Friday Sale. Bargain!
I had hoped that I could get a significant performance boost with some of the extra features in the pro version but I’m not really seeing any: any advice on the following would be greatly appreciated
In Aron’s guides he says using the multi-threading option can settings can really help performance. When I check 8 threads or either of the 2 auto modes there is absolutely no difference in frame rate compared to just the one thread. Using 100 AI’s, NavGrid with AIPath and Raycast modifier on a large 90x90 grid @ 0.3 grid size - all cores seem to be hovering around 50% both before and after selecting multi-threading. It functions great but not the performance boost I had hoped for. Is this usual?
Another reason for going pro was to try out the NavMesh option. Followed all of the guides to set up and it generates what looks to be a very reasonable map; not too dense. Using RichAI with this in exactly the same scene as above but its actually way slower than the NavGrid version (NavGrid ~ 130fps and NavMesh ~ 110fps). I have spent a long time ‘tuning’ the settings on both but its really not making much difference. I had, once again, expected this to be much faster than a NavGrid?
Are my expectations too high?
BTW I know 130 fps is very decent but I still need to add quit a bit more to the game so I do need the headroom
It seems odd that all cores would be hovering at around 50% before using multithreading? Most cores shouldn’t be used much at all then.
If more cores are worth it depends on how much pathfinding you are using, if your agents recalculate their paths quite seldom it is entirely possible that one thread is sufficient. Note however that even if one thread is entirely overloaded, the result will usually not be a decrease in the framerate (because pathfinding runs in a separate thread), but instead you would see your agents behaving strangely because it will take a really long time to update their paths. Responsiveness will take a big hit. The calculation times for the individual paths will not be longer, but because there are so many requests, they might have to wait in a queue for a long time before they start to be calculated.
You can use the Unity profiler in the timeline view to see how much work the pathfinding threads are doing. Each pathfinding thread will be visible in the timeline view.
The RichAI script is usually about the same performance as the AIPath script, sometimes a bit slower depending on the options used. However pathfinding on a navmesh graph is usually much faster because it contains a lot fewer nodes, so the load on the pathfinding threads might be lower (a 90x90 grid is quite small though, so the difference will not be that large). Note that when using the RichAI script, you should not use the Raycast Modifier, the RichAI script will not use the output from that, so it is just wasted CPU cycles.
Also note that on a quite beefy computer with many cores, reducing the load on the pathfinding threads will often not cause any difference in FPS because the cores are just laying mostly idle otherwise anyway. But on computers with fewer cores the pathfinding will start to compete for resources with for example the Unity rendering threads, and then it can start to affect performance a lot more. If you are going to use local avoidance, those threads will also compete for cpu time with the pathfinding threads.
What is the limiting factor in your game is hard to tell, you should use the Unity profiler to see what is the slowest part of the game. But there is very little difference in the performance of things that run on the main thread between the free version and the pro version.
Many thanks for the quick and detailed reply. Sorry I haven’t replied sooner, i have been working away from home
I take on board all that you are saying and I have tried to do a side by side comparison in a ‘standard environment’ by that I mean that the scene is identical but with different NavMesh/NavGrid and AI scripts.
I have uploaded a video of the results up to YouTube here: https://youtu.be/U_WuLz8qPpo The test is deliberately stressing on the system. As you can see the NavMesh is somewhat slower than the NavGrid, although the difference in one of my real game scenes is quite a bit bigger.
I’ve tweaked the various settings a lot but nothing seems to make too much difference. If you could spot anything obviously dodgy in my setup then I’d be grateful if you could point it out to me.
I also have a second question, I hope you don’t mind me asking. In both scenes I am using collision avoidance, in the NavGrid scene I check the “Constrain Inside Graph” option on the AIPath script as per your online instructions. I need to use this option. However I am sure that you will see some of the AI’s get stuck on the obstacles with this enabled? Is there anyway around this? Once again I have tried many settings but always something gets hooked up on an obstacle.
If I un-check the constrain within graph option all AI’s flow smoothly.
The AIPath script is a bit faster than RichAI, which is why your FPS is a bit higher for the grid graph. This is true in my tests as well, the RichAI script does things in a slightly fancier way (which is also why it often works better, performance/quality trade-off). Note that you can use the AIPath script with the recast graph as well. There are very few options on those scripts that actually affect performance, the ‘constrain inside graph’ option does cause a slight performance hit, but that’s pretty much it.
The pathfinding latency when using the recast graph is much better than when using the grid graph. Take a look at when the agents start moving, in the grid case some agents don’t start to move until several seconds after the game has started while in the recast graph case they all start to move at the same time pretty much immediately. This is because pathfinding on a recast graph is so much faster than a grid graph (because it contains a lot fewer nodes). This is also the kind of difference you would see between using few threads vs many threads.
When testing performance, I would also recommend that you disable ‘Show Graphs’ as rendering the graphs can impact performance a bit. Also make sure that path logging is disabled (A* Inspector -> Settings -> Path Log Mode = None).
Your grid graph resolution is very high for that environment though, you can probably reduce it quite a lot and still get decent paths.
I suspect that the agents getting stuck when using the Constrain Inside Graph option is a variant on the issues explained here: https://arongranberg.com/astar/docs/aipath.html#pickNextWaypointDist specifically check the video for when using a ‘too high’ value (note that what is ‘too high’ is environment specific). So reducing the pick next waypoint distance could probably fix it.
Wow, hadn’t noticed that latency issue with grid graph until you pointed it out.
I have had a play, as you suggested, with the “Pick next Waypoint Distance” and, yes I can make things better but not completely stop all the AI’s getting stuck.
Anyway, I’m now convinced that the ReCast is the way to go based on your comments. I’ll continue to try to eek out a few extra FPS’s from the settings. It seems that by increasing the re-path rate in AIPath and also dropping the target FPS in the RVO simulator I can boost my performance quite a bit (I have a lot of very slow moving zombies)
Thanks for the wonderful support. This is a great product.
Make sure you also check the performance optimizations you can do at the bottom of this page https://arongranberg.com/astar/docs/optimization.html (about editing the AIPath script), those are ones that I can unfortunately not expose as simple checkboxes in the inspector because you literally have to edit the code to make it work.