Arbor

Hi. We are trying out the trial version of Arbor 3. While we really like it so far, there is one major issue that is a deal-breaker right now. Since we are using the trial, we can't check the source to fix it ourselves.

When we have the Arbor Editor open for an FSM, and there is at least one state with at least one behaviour, the CPU usage goes to 25% (2 cores fully loaded) and GPU usage to 30%. Mind you, that is in the Editor, no play mode. So nothing is actively running. When we close the Arbor Editor, the usage is back to normal (0% when idle). We tried disabling the "Live Tracking" button.

We have seen the issue in both Unity 2019.4.16f1 and 2021.3.22f1. It is very easily reproducible in a new project:
1. Make a new project
2. Add an Arbor FSM to the scene
3. Open the editor for the FSM
4. Add a state
5. Add any behaviour to the state
6. Open Task Manager and check the CPU/GPU usage of the Unity process. Make sure that you put the Unity window back into focus by clicking on it, otherwise it will pause and have 0% usage.

The issue goes away if you remove all behaviours again. Sometimes it stops for a moment after recompiling scripts, but then it starts again when you interact the with Arbor Editor in any way.

Other info:
Windows 11
Arbor-Trial-3.9.5
Reproduction project (2021.3.22f1) attached.

Is there anything we can do to fix it?

Thank you for your report.

The reason for the high load of the Arbor Editor is because IMGUI is used in the Editor of Behaviour and other elements.
This is currently a specification, but we will continue to improve it to reduce the load in the future.

Here are some temporary measures:

• Click the gear icon in the toolbar and turn off "Show Grid."
• Collapse Behaviours by selecting "View > Collapse All" in the toolbar.

However, even if you perform these actions, the load reduction is minimal.
If you are concerned about running it outside of editing or testing, please close the Arbor Editor each time.

Thank you for the reply.

I don't see the suggested options reducing the load in any way. I guess the window is running at a virtually uncapped framerate because the IMGUI system (profiler shows the editor runs at around 400 with Arbor Editor open). So any reduction in load just results in more frames. In fact, collapsing all behaviours in an FSM with only 2 behaviours increases GPU load consistently from 30% to 50%, while maintaining the same CPU usage as before.

I understand that we can close it so it does not impact runtime performance of our app. However since we use laptops it is a little overkill to have them blowing loudly non-stop when editing a simple FSM graph. Even on pcs though, the added power draw and wear on the machine is comically disproportionate to the task being performed (basically showing a static image).

I can't seem to find any info online to properly limit Editor or OnGui/IMGUI framerate. Do you happen to know if that is possible?
If not, is it possible there is some issue that occurs when any behaviour is added? Because as I reported, the issue does not occur when there are no behaviours (but there are states that need to be drawn).

The high load of IMGUI is a Unity specification and cannot be reduced as long as rendering is involved.
The basic part of Arbor Editor has been switched to low-load UIElements, but the built-in Behaviour Editor has been postponed due to the high number of them and the high cost of work.
As mentioned before, this is currently a specification, but we will continue to improve it to reduce the load in the future.