Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

BuildPlayerWindow.OnGUI.mouseUp during build WebGL

x56sandmanx

During build time in WebGL, the window "BuildPlayerWindow.OnGUI.mouseUp" will pop up and remain the task from anywhere to 8-12 minutes before actually starting the build. This was not happening before importing spine into my project, and started occuring every time i build after importing spine. Just wondering if anyone else had had this problem or not. Build still works and builds, just will get stuck on this first step first for about 10 minutes. Thank you!

Harald

Sorry to hear! Which version of the spine-unity runtime (name of the unitypackage, also listed in Assets/Spine/version.txt) are you using?

If you are using a rather recent version of the spine-unity runtime, could you perhaps send us a minimal Unity project that still shows this issue? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.

x56sandmanx

Package version: spine-unity-4.0-2022-06-09.unitypackage and I am using Unity 2020.3.23f1. I do not get this problem when creating a minimal unity project with spine imported, but with my larger projects, this problem occurs, I can still send the minimal project for you to look at if you want me to.

Harald

Thanks for the info. We would need a project that reproduces the issue, if a minimal project does not show the problem it would not be of much help. So if possible, please send us a larger project where the issue can be reproduced.

astro75

We encountered the same issue after upgrading 3.8 -> 4.1. And I figured out what causes this long hang up when building the client. It is caused by Spine.Unity.Editor.SpineBuildProcessor.PreprocessSpinePrefabMeshes. It takes 5 - 15 minutes. I disabled code that calls it and the problem disappeared. Now the build time is back to 1 minute.

It also does not make sense for us to run that code, because we build assets into bundles. Assets are not built when building the client.

Harald

Thanks for sharing and sorry for the troubles. We are already aware of the problem as described above, but we would require a reproduction Unity project that shows this issue. If anyone could share such a projecproject with us, please send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

PotatoVeg

Hi,

I have been looking into this issue as I am suffering from it as well.
I have found that inside Spine.Unity.Editor.SpineBuildProcessor.PreprocessSpinePrefabMeshes it is performing the line
var prefabAssets = AssetDatabase.FindAssets("t😛refab");

Performing AssetDatabase.FindAssets without any specified folders to search in will cause a search in the entire project therefore a project with 500 files will not suffer from that issue while a project with 5000 files will.
Now... take in consideration that not all those 5000 files are prefabs, perhaps 400 of them are prefabs therefore it will search in another 4600files for no reason and causing a bigger hang on the build.

By assigning specific folders where I know I have prefabs (regardless if they have spine components inside them or not, that is too much deep filtering) I have managed to reduce the hang time on BuildPlayerWindow.OnGUI.mouseUp quite significantly.

Therefore I would recommend to add somewhere in Spine's settings an array of string (for folders) which it will perform that instead of the customers (the developers who use Spine) going into the code of it and changing it manually.

Harald

Thanks for sharing your experience and for digging into this! Sorry to hear you're having troubles as well.

Are you just suspecting that the AssetDatabase.FindAssets("t:Prefab"); call is causing issues, or did you verify that you experience a delay with this line present and could remove the delay entirely by commenting out the line (or adding an early-out return)?

PotatoVeg

It's important to note that I am building for Windows standalone 64bit which is different than WebGL platform that OP mentioned.

To your question:
If I comment the line

AssetDatabase.FindAssets("t:Prefab");

then the delay is removed entirely.

I have decided to check what is happening if I do let it stay and check the rest of the process and I have found that
most of the hang up is coming from around

AssetDatabase.LoadAssetAtPath<GameObject>(assetPath)

and

SpineEditorUtilities.CleanupSpinePrefabMesh(prefabGameObject)

.
I am suspecting those areas because the current test I ran the build finished completely in 2:30min but 1:36min of it was up until the point above the lines listed above (after the entire foreach loop has ended and it reached

AssetDatabase.StopAssetEditing();

).
Be aware that it's not always going to take 2:30min for a build, yesterday it took me more than 11min. The times are completely random it seems.

Harald

Thanks for the additional info! We have re-opened the issue ticket below and will do our best to improve the situation as much as possible:
https://github.com/EsotericSoftware/spine-runtimes/issues/1273

PotatoVeg

That's Great news! hope a better solution will eventually be found.

A few things I want to add:

1) Correct me if I am wrong on this but the comment that astro75 made about him building the assets into AssetBundles and therefore performing PreprocessSpinePrefabMeshes does indeed not make sense from the simple reason that AssetBundles and Addressables (the upgraded version of AssetBundles) are building the chosen assets into files already and the option to include them in build will just copy them into the game's various folders where Unity needs them to be and not really "rebuild" them therefore if your assets are already in AssetBundles then its pointless to let PreprocessSpinePrefabMeshes run.
If any changes to assets that were classified as AssetBundles or Addressables and a person makes a build without building AssetBundles or Addressables will result in the changes to the assets not actually being applied depending if the AssetBundles or Addressables are stored on a server or locally.

2) Personally me and my Team Leader noticed it started happening after updating to the latest version of Spine, I am not fully following all the changes on each version therefore I do not know if PreprocessSpinePrefabMeshes was in previous versions (We never skip versions, we go from one to the other when they get released).

3) I would recommend adding somewhere in Spin settings a checkbox to disable PreprocessSpinePrefabMeshes if the developer does not need it to run since when Spine will release another version the custom modifications the developer done to the code will not be override and he will need to remember to do it again every update.

All the points above are my opinion and are not demands or requests for anything, I am providing some information to make everyone's life easier if possible.

Harald

Thanks very much for your input, always much appreciated! We will of course consider it in trying to find the best possible solution. In case the problem cannot be avoided altogether, we will at least provide options to disable the time-consuming post processing step.

FYI: we have just added a Spine Preferences parameter to disable the timewise costly pre-processing step. This will at least allow the situtation to be improved until it's properly resolved.

From the changelog:

Added Spine Preferences setting Prefabs - Optimize Preview Meshes. When enabled, Spine prefab preview meshes will be removed in a pre-build step to reduce build size. This increases build time as all prefabs in the project will be processed. Defaults to false to not slow down builds substantially every time.

A new 4.1 spine-unity package has been released:
spine-unity Download