• Editor

  • Editor frame rate performance issues

Related Discussions
...

Hi there,

I usually make animations that involve two separate skeletons interacting, so I need to visualize both of them at the same time in the editor. And they're pretty complex...:

Well, I've reached a point where my frame rate when playing my animations in the editor have dropped below 30fps, even when my target fps is set to 60 in Settings and I've also set Multisample anti-aliasing to None.

This is obviously affecting my ability to judge if an animation will be playing at an adequate speed in Unity, which uses 30fps as default. I know I can modify its playing speed afterwards, either in the editor or in Unity, but I'd very much like to return to the happy times when my anims played just right in Spine. :p

So I've been thinking which of my PC components would be the responsible for this lack of performance. My PC is not state-of-the-art...:

CPU: i2500K
RAM: 16 GB (pagefile on SSD)
Disk: 250GB SSD
Video: nVidia 770GTX

...but and as I don't have any performance problems in Unity, even without compiling the game, I think the problem must come from the CPU not being able to keep up with Spine editor's calculations.

However, when I play the animations in the editor and I go to the task manager in Windows (10) I see that the total amount of CPU used by Spine tops at 35% only... :wonder:

I suspect that Spine doesn't make the most of multi-threading CPUs (?) for any reason I won't dare to theorize. I'm ok with that anyway. There are a lot of apps that don't leverage on multi-cores as well. It's not that simple.

But my fear is that I buy a last generation i7 CPU and that 35% drops to 15% and my play speed still is like 20fps like now. That would royally suck. :p

So... could I have some confirmation from you Spine guys that my problem is related to a slow CPU, please? I could send over my full project if that would help.

Thank you for your time.

Thanks. At first look, not much stands out as a hotspot taking an extraordinary amount of time

it is spread out pretty evenly across all the processing that is done. We will look into it further, though I can't say how much it will be improved.

Thank you Nate.

Thing is, if you don't see anything in which I royally screwed, then the only thing I'd need to know is from which type of PC component I would benefit most...: a faster CPU or a newer video card (?). Because I don't know where those calculations are being performed actually. :think:

It's likely CPU. I'm abroad until May 2, after which I will be back to my proper hardware and can better dig into the problem.

6 days later
Nate wrote

It's likely CPU. I'm abroad until May 2, after which I will be back to my proper hardware and can better dig into the problem.

Thanks Nate.

I'm making another animation now with three skeletons involved, and frames have dropped to 16 fps. 😃 So now I'm playing at 200% to compensate.

I'm also pretty positive this is a CPU issue, because I find very unlikely that the same video card with which I'm able to play AAA games can't cope with three 2D models. Moreover, performance doesn't rise if I zoom out all the way out.

Anyway, I'll wait for your reply before I commit to upgrading my PC in one way or other.

Thank you!

Edit: btw, if CPU is indeed what I need to upgrade, does Spine takes advantage of multithreading/cores? Or do I need to aim for higher frequency cores?

Sorry for the delay. We dug into this and have fixed the problem in 3.6.17-beta. There was a large amount of work being done every frame for every attachment, even those that are not visible. You shouldn't have a problem hitting 60 FPS now!

In many cases the work does need to be done for every attachment, just not every frame. If you notice any slowdowns with such a large project, such as when dragging to manipulate a skeleton, please let us know. That likely means Spine is doing unnecessary work every frame, which is a bug we'd like to fix. We should have caught all these cases and internal testing looks good, but it's possible something slips through or future development introduces a mistake.

Spine does use multiple threads but the majority of work happens on one thread. You really shouldn't be hitting a wall with CPU performance, but in general Spine will benefit more from a higher clock speed.

Oh, but that's great! So I don't need to upgrade my rig after all.

Well, slowdowns during skeleton manipulation don't bother me much to be honest. What really is getting on my nerves is not being able to have an accurate preview when playing the animation in the Editor, ofc. That is a problem.

I'll gleefully wait for that release then. And don't worry, I'll be your official frigging-huge-project beta tester for years to come, as my work will always imply multiple stupidly detailed skeletons doing terrible things to each other. 😃

About the multi-threading behavior you describe... yup, that's pretty consistent with what I've saw in my case: reaching about a 50% total CPU time, including all four cores. So in case I'd need to upgrade I would have needed to pick an Intel i7-7700K, instead of a AMD Ryzen (which favors multi-threading over frequency), and with those reports from Intel users reaching 90ºC at random times... I really wanted to avoid buying one of those. :wonder:

Spine editor is probably not something to factor into your CPU choice if you're buying something new.
Even if you just pick any mid-range Broadwell or Ryzen processor, it will be overkill for Spine.
Barring any bugs and missing optimizations like the above problem, Spine doesn't require that much.
Just pick whatever makes sense for your heavier production or gaming needs.

I was using Spine on a Core 2 Duo and an R7 270 for years and it ran just fine even with lots of bones. (I mean it was for actual production, so it wasn't an unreasonable number of bones. We need games to be able to run properly on people's computers and devices after all.)

5 days later

@Abelius, 3.6.17-beta is up, see what you think! You also might like the mesh tools.

Image removed due to the lack of support for HTTPS. | Show Anyway

Omg it is so beautiful...
How I wish the non-beta editor had this Q.Q it would speed up so much the work I have to do in these days...
Thank you Nate >.<

Holy shit! (x2) 😃

That's an added bonus I didn't count on. It seems pretty amazing for even substituting bones in some areas. Problem with that approach is that mesh modifications are 'all or nothing', but it's still frigging useful for adjusting specific frames.

Oh, and it's playing at 60fps again...

I love you guys. :p

Great!

Yeah, I'm a bit scared people go crazy with mesh deforms. Every deform key has to start all mesh verts. Also, each vertex (a float) is stored for every bone that affects a vertex. So a mesh with 100 verts where each vert is affected by 3 bones is 300 verts, then someone goes and keys that mesh a dozen times in 20 animations = 12 * 20 * 300 = 72,000 verts stored! This affects data file size and memory consumption, but at least CPU isn't affected.

That's important to know, does this affect only mesh deformation during animations and it's safe if only bones move a mesh or is this situation potentially dangerous?

Image removed due to the lack of support for HTTPS. | Show Anyway

Probably you don't have vertices which are influenced by ALL those bones. It's per vertex. If a vertex is influenced by 4 bones, then 4 floats are stored for that vertex in the setup pose, current pose, and every key. Also, for every bone that influences a vertex, a vertex transform is calculated. You can see the number of vertex transforms in the Metrics view. Using Purge in the Weights view can remove the bone influence that is very small, which can make a big difference. See the docs for details:
Meshes - Spine User Guide: Vertex count
Metrics - Spine User Guide: Vertex transforms