I am having some issues after I converted my project to the recently released Unity 2018.3. I am using richai and rvo object avoidance. Performance is very degraded compared to builds with previous version. A lot of time seems to be spent on aibase.fixedupdate and a fair amount on rvocontroller.
When I run from a build there are also issues where the agents do not start seeking for 5-30 seconds after spawned. After they start, they just go to the first position and are not updating (should be following player). The seeking works better when running in the editor which is odd but the performance is still very bad.
The agents have a kinematic rigidbody attached.
Prior to 2018.3 performance was good and no problems either in editor or in runtime build. Have been using .net4 and il2cpp. Running latest A*, version 2.4.2.
Hi
Try to download the latest version (4.2.4) from here: https://www.arongranberg.com/astar/download. It includes some fixes for 2018.3 with the exact configuration you mention. I’m not quite sure which version you are using right now as 2.4.2 is almost definitely a typo (unless you are using a version which is like 5 years old).
From the changelog:
- Fixed a massive performance regression when using RVO together with IL2CPP and .net 4.6 due to changes in how the .net framework handles locking internally.
My bad, I did mean version 4.2.4. The version I downloaded is the same as your link. (I worked on the original problem with you and has been working great until now).
I have also tried disabling worker threads in RVO simulator. Does not seem to make any difference. All build options I used are the same for Unity 2018.2 and Unity 2018.3.
Completely removed RVO and same problems in editor and build. Aibase.fixedupdate seems to be the culprit. I am thinking something to do with changes in Unity physics updates and the way Aibase updates. New physics option “Auto Sync Transforms” is enabled to keep consistent with Unity 2018.2. When I disabled this, performance seems better but the agents never move anywhere. At the same time my other physics objects in the game move fine. I checked that Aibase is indeed doing a proper rigidbody move and not directly changing the transform position. These are kinematic rigidbodies.
Hi
Do you think you could post a screenshot of the profiler? (optionally both in 2018.2 and 2018.3)
This is with 100 agents running in the editor. Would see hardly any load from physics on older Unity version.
Okay. So that’s almost definitely caused by the ‘Auto Sync Transforms’ thing. I thought I had fixed it so that it would work even if that was disabled several versions ago though…
I have managed to resolve the performance issues on my end. I changed something in my animator/movement. So now performance is good in editor and build regardless of the “Auto Sync Transform” setting.
However I am still having the original problem with runtime builds. The seeking is quite delayed and only goes to first position. This does not seem to be a problem when running in the editor. Here is a sample video:
https://youtu.be/QlGolMwm0XE
I have also disabled Thread Count in Pathfinding settings. Problem is the same. Please let me know if there is anything off the top of your head you would like me to test on my side.
If I enable “Development Build” in build settings, problem goes away. Not sure what to do at this point as this makes it hard to get more useful troubleshooting info.
I think I have tracked it down. Using free “Log Viewer” on asset store really helped for this one as problems only appear in build (and not dev build)…
I modified ObjectPool.cs at line 35 and checked for nulls.
public static void Release (ref T obj) {
// obj will be set to null so we need to copy the reference
var tmp = obj;
if (obj != null)
{
ObjectPoolSimple.Release(ref obj);
}
if (tmp != null)
{
tmp.OnEnterPool();
}
}
Everything seems to work now but I am not sure if this is the best way to fix this. Seems to work fine but maybe something should be addressed earlier in the chain? I get the null reference everytime richai updates the destination (Repath Rate).
I had to do two separate null checks for this so perhaps something to do with locks/threading?..
