Abelius

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.
User avatar
Abelius
  • Posts: 135

Nate

Can you please send the .spine file so we can take a look at where the time is spent? contact@esotericsoftware.com

We will keep your file confidential.
User avatar
Nate

Nate
  • Posts: 9161

Abelius

Done!

Thank you very much. ;)
User avatar
Abelius
  • Posts: 135

Nate

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.
User avatar
Nate

Nate
  • Posts: 9161

Abelius

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:
User avatar
Abelius
  • Posts: 135

Nate

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.
User avatar
Nate

Nate
  • Posts: 9161

Abelius

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. :D 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?
User avatar
Abelius
  • Posts: 135

Nate

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.
User avatar
Nate

Nate
  • Posts: 9161

Abelius

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. :D

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:
User avatar
Abelius
  • Posts: 135

Pharan

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.)
User avatar
Pharan
  • Posts: 5366

Nate

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

User avatar
Nate

Nate
  • Posts: 9161

Erikari

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 >.<
User avatar
Erikari

Erikari
  • Posts: 1880

Xelnath

that looks amazing O.O :nerd:
Xelnath
  • Posts: 407

Abelius

Holy shit! (x2) :D

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
User avatar
Abelius
  • Posts: 135

Nate

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.
User avatar
Nate

Nate
  • Posts: 9161

Erikari

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?
User avatar
Erikari

Erikari
  • Posts: 1880

Nate

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
User avatar
Nate

Nate
  • Posts: 9161


Return to Editor