Hey, I just bought your Pack and I have to say its really great! I am realtive new to unity and multitheading in particular and I needed something that was faster than the built-in navMeshSytem and I am too lazy to write my own multithraded A star algorithm.
My computer has a I7 6700k and I am on Unity 2020.2.1f1 and using the beta Version 4.3.39, so this should make use of the function right? When I enable it it slows down performance significantly no matter the thread count setting.
So I am wondering, how excatly dows the system use the multithreading, the most costly task seems to be the AI.Lerp.Update() (the Movement functions when you look at it in deep profiling), and not the Calculation itself. Can that be multithreaded? And in my case there seems to be a sychronization problem if using multiple threads slows down everything right? To be clear, while using one thread I get the most FPS, less ms and while enabling multiple threads it goes down by 20FPS.
I would really like to know what the computational limits of your Project are and I am already impressed by it without multithreading. If someone could help me out here.
Best Regards
Hi
How many agents are you using?
Would you mind posting a profiling screenshot (both with and without deep profiling)?
Thanks for the fast reply!
This is with the use of 1000 agents, RecastGraph, no local avoidance, AILerp and a Simple Smooth Modifier.
A script instantiates 1000 agents and they all move towards a single target (all set on a simple plane).
4 Threads, no Deep Profiling:
4 Threads, Deep Profiling:
For using 1 thread, the profiling looks the same but more performant, I can post those screenshots too if that would help you.
Maybe its some important setting i am not getting? Or how many threads to use in general?
I hope the pictures help!
Hi
Those movement scripts (AILerp) are not affected by threading at all. The threaded parts of the package are:
- Pathfinding
- Calculating the graphs
- Local avoidance
Where are you setting the thread count?
The only reason I can think of it being faster with fewer threads is that the agents are just standing still while waiting for their path to be calculated.
You can get rid of the cost of the AIDestinationSetter by simply not using that component and instead setting the ai.destination property manually. This also helps because you no longer need a Transform for the target of each agent.
I change the thread count on the Pathfinding Component under settings.
Ahhh okay, so the movement function runs only on the main thread.
I know I am asking for a lot considering it’s handling 1000 agents pretty well, but is there any way to optimize that movement resource usage besides getting rid of the destinationSetter?
You can always write your own movement script that is more streamlined (and possibly multithreaded).
You can take a look at the tutorial here: https://arongranberg.com/astar/docs/custom_movement_script.html
1000 agents in 2ms is pretty good already I would say.
Okay thank you very much for the help. I will look into writing my own movement script.
Any idea though why calculating the paths on multiple threads throttles performance? That seems to be weird.
Not sure.
You can post a profling screenshot if you want. Also check the timeline view.
