• Runtimes

  • UE4 - Crash after upgrading 3.6 to 3.7

I just upgraded UE4 from 4.18 to 4.21, as well as upgrading Spine from 3.6 to 3.7. Now, in the UE4 editor, when I open anything that has serialized a SpineRenderer from Spine 3.6, I get a crash like this:

Default__'my_blueprint_object':'my_skeleton_renderer_component': Serial size mismatch: Got 639, Expected 659

Which makes sense, because 3.6 used RuntimeMeshComponent, and 3.7 uses ProceduralMeshComponent (completely different serializations). I'm really just looking for a way to upgrade from 3.6 to 3.7 without losing all my Blueprint and map files. I'm wondering if anyone has a fix?

I've tried renaming (in C++) my_skeleton_renderer_component to my_spine_renderer_component in an attempt to prompt it to try not to reserialize the component. I've also tried reexporting the .json/.atlas/texture, but from an updated Spine Editor, in an attempt to upgrade it, but I've had no success. Any and all help would be extremely appreciated.

Related Discussions
...

I recommend that you upgrade your project step by step, first the spine runtime to 3.7, and then the unreal version to 4.21.
If you use more plugins I recommend to update them one by one instead all of them at once. I remember trying to do that and it resulted in a big mess.

And make sure you create backup before every step.

scardario's tips are definitely worth following. However, they are unlikely to fix the issue you are having. As you identified the class hierarchy change between 3.6 and 3.7 makes it hard to fix the serialization error you got.

One way I could imagine to get this working is to fork our runtime and integrate the latest RuntimeMeshComponent from

https://github.com/Koderz/RuntimeMeshComponent

which is supposedly working now with 4.20+. Our last version of the SpineSkeletonRendererComponent that use both spine-cpp and RuntimeMeshComponent can be found in this commit:

[ue4] Fixed up spine-cpp for use in UE4.@1454f8a

You might be able to just copy and paste this component over the current implementation that uses ProceduralMeshComponent. Of course you also have to add the latest RuntimeMeshComponent plugin to your project.

We had to switch way from RuntimeMeshComponent because it was unstable and not as well maintained as we needed it to be (i.e. it took months for the update to 4.20). Not a snark towards the author of the plugin! He does it in his free time mostly as far as we can gather, and we don't have the resources to help maintaining it.

Due to this, we decided to go with the in-built ProceduralMeshComponent, as that is maintained by Epic and unlikely to break in future UE4 versions. Sorry for the pain this causes in the short term. Long term, it should give us more stability, and less of this serialization nightmare.

scardario's idea is a nice thought. But I too think it would result in the same serialization error.

The first thing I looked into was updating the latest Spine to go back to using RuntimeMeshComponent, and it seemed non-trivial.

Instead I tried using my same old version of Spine and RuntimeMeshComponent, and tried to just update those to work with 4.21. After fixing errors, The problem I face is that RuntimeMeshComponent is not rendering anything. I suppose there were changes to rendering in UE4, and I am unable to figure out what is causing things to not render. Note: RuntimeMeshComponent is still generating meshes, and collisions on those meshes, I just can't see them. Do you know what has changed in UE4 to cause this? Or any hints?

If not, I could try your idea of updating to that commit and using the very latest version of RuntimeMeshComponent, which I'm sure would be able to render properly.

Actually using RuntimeMeshComponent instead of ProceduralMeshComponent with the latest spine-ue4 3.7 branch should be quite simple:

  1. Get the latest RuntimeMeshComponent from the GitHub repo https://github.com/Koderz/RuntimeMeshComponent
  2. Add it to your UE4 project, see the changes to the various build files in this commit and do the reverse 😃 [ue4] Removed RuntimeMeshComponent. We use ProceduralMeshComponent no…@fbd8fa5
  3. Change the base class of SkeletonRendererComponent back to URuntimeMeshComponent (see this change [ue4] Removed RuntimeMeshComponent. We use ProceduralMeshComponent no…@fbd8fa5)
  4. You can keep everything else as is! RuntimeMeshComponent is a drop in replacement for ProceduralMeshComponent, so the current code in 3.7 spine-ue4 should "just work" (tm)

This should fix deserialization, unless the latest RuntimeMeshComponent code has changed so much that it's no longer compatible with its old serialization format (I have not tried, but do not believe this to be the case).

The problem with using an older, known-to-be-serializable RuntimeMeshComponent is that it doesn't work with UE 4.18+. So, while you should be able to use our latest spine-ue4 together with an old RuntimeMeshComponent, you will not be able to upgrade UE4 itself. This is what you see if using an old version of Spine and RuntimeMeshComponent. While you can fix the compilation errors, the RMC doesn't properly interface with the latest UE4 rendering APIs anymore, resulting in nothing being drawn on screen. You will have to go back to UE 4.18 for this to work.

Alright, so it was all taking too long. The reason I wanted to upgrade was ultimately that using SceneTextureLookup in a custom material expression was crashing the Mac build on 4.18, and it doesn't crash on 4.21. I learned that this is actually a bug, and not some short coming of 4.18 intrinsically. I scrapped the custom material expression for a node based solution, using SceneTexture nodes, and it solved the crash (even though under the hood its using SceneTextureLookup, it solves a missing reference crash). So now I don't need to upgrade, and will stay on Spine 3.6 for the remainder of this project. The material now is a nightmare of nodes, but at least its working. Thanks to all for your advice.

Sorry we couldn't find a better solution. I can related to the nightmare of nodes though :/