Under review

animatedfloatcliplayer

Cicaeda 1 year ago updated by Peter - Soxware Developer 1 year ago 3

Image 1333

UMotion Pro has a significant impact on code compile times, slowing down projects unnecessarily. Even without opening UMotion, simply having UMotion added to the project causes this slowdown. You can verify that UMotion is doing this crazy amount of work on every compilation by looking at in the Unity Profiler, setting it to profile Edit Mode in the top left and enabling Deep Profiling.

Something needs to be done to make it so UMotion doesn't load all this stuff in the background when it's not being used. At least not until you boot it for the first time. The AnimatedFloatClipLayer.OnAfterDeserialize() is the biggest killer, and if that could at least be gotten rid of, it would be a huge win.

UMotion Version:
1.29p02
Unity Version:
Unity 2021.4.15f1

Answer

Answer
Under review

Hi,
thank you very much for your bug report.

Is it possible that you have the UMotion Clip Editor open with a UMotion project being opened currently loaded? It's deserializing the UMotion project file that seems to be causing the impact on your assembly reload. Try closing the Clip Editor and the Pose Editor (or at least hide it in the layout by having some other windows in the same tab register in focus). The impact on the assembly reload should be much smaller in this case.

Best regards,
Peter

Answer
Under review

Hi,
thank you very much for your bug report.

Is it possible that you have the UMotion Clip Editor open with a UMotion project being opened currently loaded? It's deserializing the UMotion project file that seems to be causing the impact on your assembly reload. Try closing the Clip Editor and the Pose Editor (or at least hide it in the layout by having some other windows in the same tab register in focus). The impact on the assembly reload should be much smaller in this case.

Best regards,
Peter

Neither the clip editor nor the pose editor were open. I closed the tabs as well. I tested many times with a clean install of UMotion Pro, making sure to restart Unity without the pose and clip editor windows open. I even did a test with a clean install of UMotion Pro, never opened the clip/pose windows, restarted Unity, then profiled. It's very reproducible in all situations when you have an existing Umotion project. Deleting my UMotion projects only got rid of about 10k serialization calls, with 40k remaining. It looks like everything listed in the Clip Editor's "Recently Opened Projects" and "Restore Project From Backup" is being referenced as scriptable objects and therefore reserialized on every domain reload.

Thanks for the additional information. That does indeed sound like it's unintended then. I'm going to do some further investigations and keep you updated.

Best regards,
Peter