Hello again, I am attempting to profile my runtime build and I notice that RVOSimulator performance is below expected in my runtime build. I have about 400 RVO agents running with my RVOSimulator settings as:
symetryBreakingBias: 0.2
hardCollisions: true
desiredSimulationFPS: 30
doubleBuffering: false
I am using:
A* version 4.3.47
Windows 10
Unity 2020.3.24f1 LTS
IL2CPP with .NET 4.x
I have attached some screenshots showing what I am seeing in the profiler for both the editor and runtime. The screenshots are taken with my RVO agents in the same scenario: stationary in a rectangular formation.
As you can see in the timeline screenshots, in the runtime build, JobHardCollisions is taking 74.44ms across all threads while it is nowhere to be seen in the editor. During runtime, there also appear to be garbage allocations.
Have you seen this before? Could I be doing something wrong? Is there any additional info that could help? Thanks.
First 2 screenshots are in the editor.
Last 2 screenshots are in the runtime build.
Just wanted to add that my current solution is to turn off hard collisions entirely.
Hi
It looks like Burst is disabled in your standalone build for some reason. It’s using the C# jobs instead of burst compiled jobs.
I looked into it a bit further, as well as updated Windows, and Unity to 2020.3.25f1 LTS.
It appears that only JobHardCollisions has the problem though as my other Burst jobs still have “(Burst)” after the name in the Timeline of the Profiler as seen in this screenshot (runtime):
Also in the Editor, I did find the job which is burst enabled (editor):
And with hardCollisions disabled, the job still is not using burst, but naturally, without hard collisions, the job is much faster (runtime):
I also searched the player log for “burst” and nothing…
That is weird… Usually Unity at least logs the reason why a particular job cannot be compiled with burst. And it’s especially weird that it can do it in the editor but not in the player…
1 Like
Not sure if it’s related, but I am also seeing some behavior in the player that is different than in the Editor. My characters near a slope seem to slide down the slope for some reason, but only in the player. I thought it was a gravity / friction issue, so I scripted my own gravity solution and disabled Rigidbody gravity and friction completely, but even after doing so, the problem is still occurring.
Even after disabling RVO, there seems to be some difference in behavior between the editor and the player as a couple of my characters were still sliding near the slope. I’ll work on making a video to show and I’ll let you know if I find anything else of note.
Ok, as soon as I tried to record that issue, I began getting errors dealing with the Addressables system in the player (my luck…) so I couldn’t even get to the point that the issue occurs since it requires my characters to spawn with Addressables. After updating Addressables and spending some time fixing things, that problem is not happening anymore, which is good, but weird as I didn’t change anything else. So please disregard that last reply.
I did check to see if that fixed the issue with the JobHardCollisions not using burst, but unfortunately, it did not. I also made a build with Mono instead of il2cpp to see if that made a difference, but the JobHardCollisions is not using Burst there either.
It is weird though because “JobHorizonAvoidancePhase1 (Burst)” and “JobHorizonAvoidancePhase2 (Burst)” are both using burst in the player as well as some others from your package.
Please let me know if I can provide any additional information.
I don’t know why they wouldn’t be able to use burst 
If Unity is not giving you any information, it’s very hard to debug it. You could try deleting any burst caches?
If Unity is not giving you any information, it’s very hard to debug it. You could try deleting any burst caches?