[0:05]Welcome to Armannimation. Today we'll talk about the hardest topic on this channel: optimization of your Spine projects.
[0:12]I'm Arman, being Spine animator and having four years of codec experience in the past, I can tell you that you should not spend any second optimizing your projects that you have already done. Unless developers found some performance issues and narrowed it down to your spine projects. Dear developers, please do not limit animators without measuring your game. Honestly, you should not worry about performance at the beginning. And even if you do so, believe me, the bottleneck is most likely not spine. So, the purpose of this video to teach animators to build skeletons in an efficient way, so spine is less likely to be the bottleneck in the game. This video will also help you to construct flexible rigs with less efforts. To better understand how skeletons perform at runtime, check official documentation. I will drop the link in the description along with some other useful links. If you're animating projects to be rendered as video or sequence, none of this matters. Ignore this video. But don't just leave, subscribe, maybe next video is just for you. Let's start from Photoshop, or wherever you have your art. Mainly, animators receive the art in original size, which would mostly be unnecessary big. The size of the images in the spine can be resized during the export, so it cannot be a performance issue. However, my advice is to consider the highest resolution device that your game will run on and resize your art to match it before even importing into spine. This way you will avoid massive skeletons with bone scale cranked up. Spine can even export multiple atlases using different scale ratios, so later developers can load an atlas based on user screen size. Great, let's assume we have resized the art for our needs. What else we can do at this stage? If some of the art pieces have too much empty space, make sure to rotate them or even cut into pieces for better packing. Next, if you have some shadows, clouds, smoke, anything that is blurry and in background, you can add scale tag to it for better packing. That will make sure that exported image will be smaller, no worries, spine will stretch it back to initial size. The quality reduction should not be noticeable for our already blurry images. This will help you to pack tighter and smaller atlases.
[2:35]Once we have prepared our project in Photoshop, we are ready to import it into Spine. While rigging we should keep sight of how our assets will be used. If it's going to be low resolution on a phone, probably we don't need to rig each finger and strand of the hair individually. Don't use more bones and vertices than necessary. It can be surprising how much we can do with just weights.
[3:00]However, very often we will need mesh attachments. It is very important to resist the temptation of zooming in and adding too many details at this stage. The mesh should be functional and not looking nice. Add more details where the mesh is going to bend or stretch. If the mesh has hard parts, like this metal gear on her chest, maybe you need to preserve it with an extra ring and bind it with an equal value of all vertices. At this stage you should already know how the mesh should behave. Maybe it's going to rotate in 3D, or it's bending uniformly. So better to plan before meshing it. After you finish setting up the mesh, you will need to bind it to the bones so you can animate it. But what if we want to deform the mesh directly in animations? Why not? It is easy, you don't need to rig it with bones and weights, you have more control over vertices, and with soft selection tool you can easily warp any mesh however you want. Or check this out, we can set custom pivot for any amount of vertices and rotate or scale them. Cool, right? So with all these controls, why not to deform the mesh all the time? Well, it has two huge downsides. First problem is that a mesh can be keyed only on one timeline. So you can't animate separate portions of the mesh independently.
[4:36]The mesh will deform from key to key as a collection of points, each moving by a straight line. So, don't rotate the mesh using deform keys and expect a normal behavior. You will see it shrinking at the middle of the way then resizing back. But the main problem is that deform keys use a lot of memory to store values for every bone weighted to each vertex. And it also increases the data file size, since one of the largest parts of the skeleton data is the mesh vertex. Let me demonstrate that, I will open the Raptor project.
[5:18]Export a JSON as it is now so we can compare later. Then select all meshes and key five times.
[5:37]And now let's copy them to all other animations. And finally, export it, just rename skeleton so it generates a new JSON. Great, we have a new JSON. So we can clearly see that we have increased the size by more than twice. So, if you decide to use them, make sure there are few vertices. Or don't bound the mesh to the bones. In general, maybe a few keys and a big deal, but better to use them sparingly, or not at all. A common mistake is when you go over all animations and adjust all meshes, just to patch things up. Don't do that. Cool, let's say we have decided to bind the mesh to bones. Well, before doing that, it is important to understand where you will place the bones, especially for long attachments such as rope, tail or hair. Try to position a bone at the cross section of the triangles.
[6:40]That will improve bending. What's also important here is to weight vertices to the minimum number of bones necessary for the mesh to function.
[6:53]This allows us to modify binding easily, and we will have less vertex transforms. By binding vertex to more than one bone, we will increase the vertex transform count, which will increase the calculation time of your game. Calculations use CPU, however, it is relatively cheap. Just keep an eye on it. It also means that you need to be mindful whenever you want to smooth the weights. I normally hit once or twice. And instead of smoothing all vertices, you can smooth unselected ones. Lastly, using prune may reduce significant number of vertex transforms. Oh, and did you know that you can recalculate portions of the mesh for specific bones? So cool, right? Great, we have our mesh bound to bones and working as expected. What about clipping feature in Spine? I bet you heard that it is expensive. And according to the official documentation, it is indeed a very expensive operation for CPU. Always try to find alternatives before using clipping feature. For example, you can make holes in the face to hide the pupils. Maybe add another image over it to hide the unwanted portion.
[8:10]However, sometimes you might have no other option. Like in this example, there is nothing I can hide the pupil behind. In those cases, make sure the clipping mesh has the minimum vertices needed. Clip fewest amount of attachments and avoid meshing clipped attachments, or mesh it with small amount of vertices. And don't worry about the size of the clipping polygon, it doesn't affect the performance. Just make them convex if possible, because clipping attachment is first decomposed into convex polygons, then each resulting polygon is checked against all the clipped region and mesh attachment vertices. Cool, what if we want to fully hide some attachments? Maybe the whole character, if there are multiple attachments, you might want to go and just scale the root bone of the character down to zero in one frame. And boom, it's gone. Just make sure you break the interpolation. Sure, you can do that, just know that at runtime the character will be still sent to be drawn. However, nothing will be rendered, and setting attachments to zero transparency will still draw the image and use fill rate exactly the same way as if transparency was set to 100. So, why not just hide the attachments? Makes much more sense, right? What about animation keys? How do they affect the performance? Well, the keys just hold numbers, so more keys means bigger data files and more memory to hold the data at runtime. For example, these portions represent one key. And applying timelines uses some CPU, so fewer timelines is better. I personally never cut on timelines when I animate, I would even go and separate few timelines to have more control over them. I would sometimes even go wild and animate frame by frame to perfect the motion. So, this is another reason to rig with less bones possible, less bones, fewer timelines, and don't forget to clean up your keys when exporting for production. Next, I would say don't use too many constraints. But after double checking with Spine developers, I can say that there is no real reason to avoid using constraints. Isn't it great? But don't overdo them though. Remember, your rig should be flexible and functional to produce high quality animation in reasonable amount of time. You don't need to show off by creating monster rigs full of constraints. That was it for today, subscribe to participate in the upcoming poll, leaving a video on the screen with more tips. Bye.
