Thanks for the clarification and for posting the profiling updates!
Are you using a lot of path constraints on your problematic skeletons?
Thanks for the clarification and for posting the profiling updates!
Are you using a lot of path constraints on your problematic skeletons?
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.
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
I've attached the metrics view of one of the agent's forward facing skeleton.
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.
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.
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.
I feel things will change once Harald implements DOTS. :-)
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!
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.
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.
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.