- Uređeno
Unity - Performance issue
Hi guys.
We are developing a Unity game that uses spine and having performance issues.
We have a stage with 30 spine objects. Each has metrics that are shown in the attached image.
This stage performs 30 fps. But during the mentioned spikes it is dropping to the 15fps
We are using:
- Latest Spine Editor
- The latest runtimes
- JSON data format
Unity Profiler shows CPU spikes of functions bellow. That causes FPS to drop
SkeletonRenderer.LateUpdate();
SkeletonAnimation.Update();
We have already
- changed transitions from Bezier to Linear
- reduced the numbers of keyframes
Are there any performance improvements that we can make?
Thanks!
try to use the binary format
Does it slow down only when the spine objects first appear or does it slow down and stay at 15fps the whole time?
If it's only when they first appear, then yeah. It's likely a loading issue. For a better loading experience, it's recommended that you (1) preload them by calling yourSkeletonDataAsset.GetSkeletonData(false)
during the loading phase of your game or scene for all the skeleton data assets you need and (2) yeah, use binary.
joboldo wrotetry to use the binary format
We wish we could use it.
But there are rumors that binary exported data will not continue to work with the latest runtimes. Since we are having our data cached on the users devices we cant change exported data to be synced with runtimes.
Pharan wroteDoes it slow down only when the spine objects first appear or does it slow down and stay at 15fps the whole time?
Game having spikes during whole time. On spikes we have 15 FPS
According to Nate
If you use JSON then usually the runtimes will continue to work even if the format changes.
What's your target device?
If the game keeps having spikes the whole time, it's probably not loading that's causing the problem so it doesn't really matter if you use json or binary. I recommend json for Nate's reason and for diff tracking.
I've easily had 30 animating spine skeletons before and it wasn't hiccuping.
But as you need more and more skeletons, you'll want to make sure each individual setup is not being wasteful.
In general, be judicious about the little details you add to your multiple-spawned skeletons. When there's a lot of them, your tiny separations and animation details possibly won't even be noticeable and only hurt framerates.
This ONLY applies to skeletons you need to spawn a lot. If it's just one skeleton like your main character, the effects can be arguably insignificant:
(1) Minimize the number of keyed properties in spine. For example: If a bone doesn't need to rotate, don't give it a key to rotate. Anywhere. That item shouldn't have a row in the dopesheet. Each row in the dopesheet is extra overhead. So even if you only have 1 key on it, it'll eat up resources. (Each dopesheet row is one Timeline runtime object that the runtime has to iterate over every Update an animation makes.)
(2) Have as few bones and attachments as possible.
(3) If you can help it, don't use meshes and FFD. And if you really need meshes for these skeletons, minimize their vertex count.
(4) If your skeletons are for looping environment stuff, and you want want it to play one animation over and over, Baking may be a good option, especially if you just want it to do a Weighted/Skinned animation. Baking will take advantage of the GPU to animate the meshes and free up your CPU to do the more controlled things. For maximum compatibility with Unity GPU skinning settings, make sure each VERTEX is bound to a maxmimum of two bones.
In this context, it'd be informative if we could see what you skeleton looks like.
You can replace all the images with pink boxes if you want. Or show a wireframe of them in Unity.
I was just speculating. Your skeleton setup could be fine. But with only 30 skeletons in your game, what else could it be?
Thanks for Reply Pharan will try to reduce skeleton.
One more think with this setup we hadn't any problems with libGDX is unity handles it in a wrong way? what is the difference in implementation of unity and libGDX
Mitch wroteWhat's your target device?
warmanw wroteOne more think with this setup we hadn't any problems with libGDX is unity handles it in a wrong way? what is the difference in implementation of unity and libGDX
Unity does a lot of things differently. It's a bit heavier because it tries to do a lot of things for you.
What IS your target device?
I have tried using Spine Unity running about 25 skeletons (that weren't too simple but didn't have meshes yet).
It ran really fast on a Galaxy S3. Probably 15fps on a Galaxy Tab 2. These are ancient devices by now.
Hi
We run on nexus5, nexus3, fire HDX 7 etc.
I guess we are having problem with Shaders since we use Sprite/Default instead of shaders in spine package.
can Shaders cause this issue
P.S. We tried to change Shaders to Spine/SkeletonGhost it worked but it is not visible when we run on android so we changed back to Sprite/Defaults.
Is there any topic about this issue?
Try the Spine/Skeleton shader?
Spine/Skeleton was showing some outlines so we thought is is a bug and changed back to Sprite/Default
but we found the solution here
viewtopic.php?f=3&t=2132
And it worked.
Last thing guys can it be that if we use Spine/Skeleton instead of Sprite/Default it will increase CPU performance?
Spine/Skeleton is pretty much as simple as possible. You'd have to compare it to the source of Sprite/Default.
Those are two different shaders. They won't affect the CPU at all.
Spine/Skeleton should theoretically run faster on the GPU if you disable shadow casting.
Whether or not it actually is, that remains to be tested.