atrivedi

Hello! I have a game running on Xbox One using GDK. I have ~25 spine animations on screen and I'm noticing a non-trivial performance impact. The game runs at 60+ fps without them and around 30 fps with them.

I do have code in my project to update spine files offscreen at a lower frame rate (by manually calling Update(); and LateUpdate() with a larger deltaTime and load balancing those update calls across frames), but again those are for off screen spine files. For all spine files on screen, I let their on Update(); and LateUpdate(); get called through the normal flow

Should I be observing performance degradation with ~25 spine animations on Xbox One using GDK?


Thanks in advance!
atrivedi
  • Сообщения: 8

Harald

atrivedi писал(а):Hello! I have a game running on Xbox One using GDK.
I'm afraid I don't know what GDK is in this context. Could you perhaps share a link or spell out the full name of the acronym?
atrivedi писал(а):Should I be observing performance degradation with ~25 spine animations on Xbox One using GDK?
It depends on your skeleton complexity, the number of draw calls your skeletons need, and the like. Please see this documentation section here: Metrics - Spine User Guide: Performance

Did you perform some profiling? Is most of the time spent in Update or LateUpdate of SkeletonAnimation? What is the impact of the offscreen skeletons, how much does the framerate improve when completely disbling them?

It might even be your build settings that cause very bad performance, as seen in this forum thread:
Unity パフォーマンス問題について
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

atrivedi

Hi! Thank you for the response!

Apologies for the confusion. GDK (short for Microsoft Game Development Kit) is the new build pipeline for XBox One, XBox Series, and Windows 10 from Microsoft. It is their replacement for XDK and UWP pipelines.

I will take a look at that link, thank you for sharing!

I have done profiling. I found that most time is spent in Update() which calls Skeleton.UpdateWorldTransform() which calls PathConstraint.Update().

I did see that post you linked, and I think we are already using IL2CPP, but I will double check.

---

Update to confirm we are indeed using IL2CPP. However, upon reading the thread again, I see there are levels. I will with different optimization levels

---

update update, there is no optimization level for this build pipeline. I was confusing one of the options with optimization.
atrivedi
  • Сообщения: 8

Harald

Thanks for the clarification and for posting the profiling updates!

Are you using a lot of path constraints on your problematic skeletons?
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

atrivedi

We are using path constraints, but not sure what "a lot" would be. I did confirm with the animator they use path constraints all over the place.
atrivedi
  • Сообщения: 8

Nate

What "a lot" is can vary, a lot. You may need to experiment to determine what is too much. Can you post a screenshot of the Metrics view for one of your skeletons?

Some things are mentioned here:
Metrics - Spine User Guide: Performance
Аватара пользователя
Nate

Nate
  • Сообщения: 10750

atrivedi

I've attached the metrics view of one of the agent's forward facing skeleton.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
atrivedi
  • Сообщения: 8

Nate

That looks like a roughly medium weight skeleton. Profiling can be misleading sometimes. You could remove all the paths temporarily and see what the difference is. With 25 of these on screen at once it's about 16k vertex transforms, which I'd guess is the bottleneck. Has the animator tried using prune to reduce vertex transforms? As mentioned at the link about performance above, generally fewer bones and fewer vertices means less work for the CPU to do.
Аватара пользователя
Nate

Nate
  • Сообщения: 10750

atrivedi

Thank you! We have done a test with removing the paths and it does help performance a bit. In theory we could have the animator reanimate them all, but that would take a long time (something we just don't have a lot of haha). We also did a test with prune and the animator had even removed vertices that were in use to lower the count, but it didn't give us noticeable gains.

We are using spine 3.8 and I see 4.0 is in beta. Are there notable improvements to performance in there and would it be worth upgrading to get those improvements? We could of course try it, but just wanted your thoughts on it.
atrivedi
  • Сообщения: 8

Nate

I don't think there will be much performance difference with 4.0, but it may be worth a try. Animations store and apply curves a little differently, but you'll still have a lot of computations.

How many paths do you have? You could try unchecking Constant speed for your paths, or for some of them. This reduces the computations required, but you'll want to check that the animations still look right.
Аватара пользователя
Nate

Nate
  • Сообщения: 10750

foriero

I feel things will change once Harald implements DOTS. :-)
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Аватара пользователя
foriero
  • Сообщения: 439

atrivedi

Thanks Nate, we'll look into that!

A DOTS implementation would be awesome!

---

Hi, just wanted to report what the optimizations where and what we were able to trim the numbers down to. Was wondering if this gives anymore insight on your end. Thank you!
У вас нет необходимых прав для просмотра вложений в этом сообщении.
atrivedi
  • Сообщения: 8

Nate

Thanks for following up! The lower numbers are of course better. Was there a noticeable performance difference? I don't think your skeleton is unreasonable at all. The metrics don't show everything of course, eg how many paths. We'll see about adding that. x25 of these skeletons is still a lot of processing (~10k vertex transforms) but it's very dependent on the hardware.

Did unchecking constant speed help?

Still curious how many paths you have. You can filter the tree to only show paths, select the first, then shift+click the last to select them all and it'll tell you how many paths are selected in the tree properties.

Oh, also how many path constraints do you have? Each one does a fair amount of calculations (see the PathConstraint class). The PathAttachments themselves do very little. It can't be more than 6, since your metrics show 6. I'm surprised paths are giving you such trouble with 6 or fewer path constraints. I'm not sure I trust the profiler.
Аватара пользователя
Nate

Nate
  • Сообщения: 10750

csumsky3

Hello Nate! This is Chris, also from the Moonlight Kids team! I can help answer some of your questions, to keep communication flowing:
The lower numbers are of course better. Was there a noticeable performance difference?
Unfortunately not really, no. Maybe a frame or two, but it was hard to tell. No major change in performance stood out though. As you said, our skeletons already weren't that unreasonable, so perhaps those stats just aren't the bottleneck.
x25 of these skeletons is still a lot of processing (~10k vertex transforms) but it's very dependent on the hardware.
Yea, and we're talking 60-70 of these skeletons (plus 2-10 more for Player Characters and any on screen enemies) when the game is at it's most stressed. On old Xbox One hardware to boot (not exclusively, but that's our most problematic hardware at the moment).
Did unchecking constant speed help?
Our animator has just recently made this change, so we'll be doing build tests asap! Will report back when we know.
Still curious how many paths you have. You can filter the tree to only show paths, select the first, then shift+click the last to select them all and it'll tell you how many paths are selected in the tree properties.
Our animator checked and he says there are 4.
Oh, also how many path constraints do you have? Each one does a fair amount of calculations (see the PathConstraint class).
Our animator says also 4. To quote him: "I always use them together I never do paths without a constraint. So 4 paths and 4 path constraints"

Hope that helps give more info and context! We'll report back on the Constant Speed test asap.
Аватара пользователя
csumsky3
  • Сообщения: 25

Nate

Thanks for the additional info!

With just 4 paths and constraints, it doesn't seem like path constraint should be a bottleneck. I have a feeling the profiler may be misleading. Maybe there are different types of profiling or profiler settings you can try.
Аватара пользователя
Nate

Nate
  • Сообщения: 10750


Вернуться в Unity