It's an issue in UE4 we've been trying to fix for over 2 years. Spine needs to update collision meshes of ProceduralMssh each frame. It seems UE4 doesn't like that at all. Worse, in the editorz it also creates gigabytes of data on disk.

I fear we'll have to remove collision mesh support from spine-ue4 entirely. Users will have to create custom collision shapes and attach them to their actor themselves.

Yes, until i remove the physics code entirely from spine-ue4, setting it to NoCollision should do the trick.

Mario I also encountered this memory leak issue in our project, and it's a serious problem. I tested it using UE4's performance analysis tool and found that even when doing nothing, Spine would have a memory leak of 2MB per second, which is similar to the memory leak from the physics module mentioned by the questioner. I have reviewed your rendering code and it seems obvious to me that the way to fix it is to avoid creating the Mesh every frame, as it's unnecessary. You only need to recreate the Mesh when it's updated; otherwise, you just need to Update it. I tried modifying the rendering logic of the SpineRenderer, and the memory leak disappeared. I wonder if you could consider making this change officially, as it's a very serious issue.

Mario
I also encountered this memory leak issue in our project, and it's a serious problem. I tested it using UE4's performance analysis tool and found that even when doing nothing, Spine would have a memory leak of 0.2MB per second, which is similar to the memory leak from the physics module mentioned by the questioner.
{TEXT?}

I have reviewed your rendering code and it seems obvious to me that the way to fix it is to avoid creating the Mesh every frame, as it's unnecessary. You only need to recreate the Mesh when it's updated; otherwise, you just need to Update it. I tried modifying the rendering logic of the SpineRenderer, and the memory leak disappeared.
{TEXT?}
I wonder if you could consider making this change officially, as it's a very serious issue.

I found that I can't send pictures about memory testing in the post content, but it doesn't matter. I will roughly describe the modifications in words: 1. In the SpineSkeletonRendererComponent.cpp file, modify CreateMeshSection() to UpdateMeshSection() in the Flush() method, of course some judgments need to be made to determine whether to update this MeshSection; 2. At the same time, comment out the original ClearAllMeshSections() statement in the USpineSkeletonRendererComponent::UpdateMesh(Skeleton* Skeleton) function.

There is no way to determine if the mesh needs updating or not. Your point 1. of "of course some judgements need to be made to determine whether to update this MeshSection" is exactly the issue. You can possibly fix this for a handful of assets in your specific game, but there is no way to fix this for every possible project out their generally in the runtime.

You are also not fixing the memory leak. You are just making it take longer to become apparent.

This needs to be fixed on Epic's side.

Mario Of course I'm not very familiar with your internal Spine code, but at least with some simple judgments, we can complete the determination of how to update MeshSection, which can handle simple scenarios and reduce 99% of memory leaks. This is at least better than doing nothing. You should know that a memory leak of 0.2MB per second can make this plugin very difficult to use on mobile devices.

There are no "simple judgements" we can apply to our general spine-ue runtime. As I explained, you can do that on your end, by modifying the spine-ue sources with the full knowledge of your project. We do not have that knowledge, neither for your project, nor for anyone elses projects. We therefore can not apply such "simple judgements". They don't exist. I'm happy to integrate anything that's general enough that you came up with.

And as I explained in my last post as well: you can not get rid of the memory leak. You are simply post-poning the time of crash. The leak is still there. It is a UE problem, not something we can fix on our end.