Contents
Introduction
This section discusses various performance-related issues.
The content is primarily intended for programmers.
MagicaCloth performance dependent
MagicaCloth runs on the Unity DOTS (Data-Oriented Technology Stack).
Therefore, it is completely CPU-dependent.
Conversely, it does not use the GPU at all.
In addition, DOTS supports multi-threading, so the higher the number of CPU cores (threads), the better the performance since parallel execution is possible.
However, a little caution must be exercised when using it on Android/iPhone.
CPUs in mobile devices are generally formed with a big core configuration and a small low-power core configuration.
This is called the Big-Little configuration.
For example, even if a terminal has an 8-core CPU, in most cases it is divided into Big4/Little4 and so on.
In this case, it is described as (4-4 cores).
Unity will only run DOTS on the Big cores.
Therefore, in the case of the above device, only 4 of the 8 cores can be used for DOTS.
Please note this point.
This problem does not occur with desktop PC CPUs.
Creation and execution of cloth data
MagicaCloth requires a variety of data to perform simulations.
This is called cloth data.
Cloth data is then generated on-the-fly at runtime as requested.
The creation of this cloth data requires a considerable amount of computational processing and usually takes 20ms to 100ms.
This creation process is executed in a background thread, so it has little effect on the main thread.
In addition, multiple cloths are created in multiple threads, which are executed in parallel.
However, the simulation must wait until this cloth data is completed.
This causes a delay of several frames between the actual creation of the character and the start of the simulation.
Notes on Editor Execution
The Burst and JobSystem used by MagicaCloth are more demanding when running the editor than when building.
Therefore, please note that the contents of the profiler when the editor is run are not the same as when the build is run.
This is due to the following factors
Burst JIT Compiler
Burst is compiled at runtime (Just-In-Time Compiler) only when running in the editor.
Since this is done after play has started, the first time MagicaCloth is used, the compile time will be several hundred ms or more.
Thus, in the editor environment there is a significant delay before the first simulation starts after play.
This problem only occurs in the editor environment and not at build time.
To work around this problem, use the Enter Play Mode Options as follows.
This is located in the Editor tab of PlayerSettings.
By using Enter Play Mode, Burst will not be JIT compiled again after repeated play operations.
JobsDebugger processing load
In the editor, the JobsDebugger is constantly monitoring the job’s operation.
This causes jobs to take longer than usual to execute, and unnatural gaps occur between jobs.
If you are concerned about the load, please turn off JobsDebugger as follows.
SafeCheck processing load
Similarly, the editor environment is monitored for Burst safety.
Since this load also occurs to a certain extent, please turn off the following two checks if you are concerned.
Note that errors will no longer be reported.
Note, however, that if you turn off JobDebugger and SafeCheck as described above, Burst/Jobs errors will not be displayed.
Therefore, if you feel that MagicaCloth is not working properly, please turn all checks back ON and check for errors.
Fastest at build time
Note that MagicaCloth’s performance is lower at editor runtime than at build time due to the various monitoring tasks.
In a release build, all of these monitors are eliminated.
Therefore, it is best to build and check actual performance on the actual device.
List of processing loads
This section describes the most processing-intensive of MagicaCloth’s functions.
The more ★, the higher the load.
Cloth type
| MeshCloth | ★★★★ |
MeshCloth is considerably more demanding than BoneCloth because it involves proxy mesh skinning and writing back to the render mesh in addition to simulation. Therefore, please pay attention to performance when using mobile devices. |
| BoneCloth | ★ | BoneCloth is very lightweight. In most cases, it can be used in large quantities without causing problems. |
Collision processing
| Self Collision | ★★★★★★★★★★ |
Self-collision is a prominent and demanding process among all functions. If used on a mobile device, reduce the number of vertices in the proxy mesh as much as possible and pay close attention to performance. |
| Mutual collision | ★★★★★★★★ |
Mutual collision is slightly less demanding than self-collision because it only determines collision with the other party. However, since the process is no different from self-collision, please pay close attention to performance here as well. |
| Edge Collision | ★★★★ |
Edge collisions are several times more demanding than point collisions. Try to use this only when there is a problem with point collision. |
| Point Collision | ★★ |
Point collisions have a far lower processing load than other collision determinations. |
| Backstop | ★ |
Backstop has the lowest processing load because it requires only a few calculations. |
end.