June 29th, 2020
Welcome to the team, Siniša! Tell us a little bit about yourself and your background.
Hello! I am an animator from Zagreb, Croatia. Like many other artists, as a kid, I loved cartoons, comics, movies, games, and of course dinosaurs. And I never stopped being that kid. I enrolled in the animation department at the Zagreb Art Academy. Zagreb in the 60s had a really strong style called “Zagreb school of animated films”. That was a big inspiration for me and it was my luck that the teachers from the Academy were trained by the old masters. At the Academy we were taught to animate on paper, old school, and this taught me to plan my animation before I hit the desk. As an animator hungry for more knowledge, in 2012 I enrolled in The Animation Workshop in Denmark to learn 3D Character Animation. That expanded my horizons and made me a more versatile artist. I met some wonderful people and some amazing instructors that came from big studios like Disney, Dreamworks, Pixar, and Sony. After that, I understood how much more there was to learn and I continued to educate myself. I landed in the Czech Republic at Anomalia to study and practice more 3D with other talented students and teachers. After that, I keep enrolling in online courses and creating routines to practice my drawing skills as well. Besides all the studying, I have worked around Europe on series, short films, features, VFX, commercial, games, and now finally with Spine.
What brought you to Spine?
It’s actually a fun story. My wife is Spanish and she was taking Croatian classes around 2014. The two struggling students of the class were her and an American. One day when I came to pick her up they were chatting about their struggles with the language and we went for a drink and when he explained to me about the software that he created -- I was so impressed! And... that’s how I met Nate. I got a firsthand introduction to the world of Spine.
What's your role on the Spine team?
I approached Nate with the idea to make a series of video lessons. I collected a lot of materials through the years and I wanted to share that knowledge. Especially as I do both 2D and 3D animation, Spine is a perfect mix of both. A lot of indie teams are often very small and many times developers and artists are not trained in animation. These courses will be perfect for them. We will start with the basics, with emphasis on making it easy to follow. Then we’ll move to an intermediate level where we’ll see the typical animation cycles used in videogames, exploring different animation styles and techniques. And then some advanced techniques where we will tackle all sorts of things: combat, acting, and a lot of other tricks to get that fine polish look.
Question from the audience: what is your all-time favorite video game?
That’s a tough one. I started to play games on a Commodore and Atari. One day my mother brought us an Apple computer from work, and then I discovered the original Prince of Persia. Until then, the game I had seen only had squares moving around, but this game was much different -- the character moved so fluidly. Later I found out that the developer actually recorded his brother moving around and rotoscoped him. Genius! After that I was hooked on 2D point and click adventures, like Monkey Island, Day of the Tentacle, Discworld, and my favorite Full Throttle. But again Prince of Persia came back to surprise me, this time the Ubisoft version, The Sands of Time. This updated version was impressive with its movement and acrobatics and it set a precedent for other videogames like Assassins Creed (which I also quite enjoy). The last game I played was Spiderman from Insomniac Games, which is such a wonderfully animated game. It looks beautiful, the gameplay is nice, the story as well but the animation, it’s just perfect. I would probably put Bloodborne at the top of my list because I like to torture myself, but as a favorite, I think that I will keep Prince of Persia, The Sands of Time. That game was a revolution and I really hope to see another sequel.
Say "Hello" to Siniša on the forum!
June 15th, 2020
In this blog post we will create a rotating diamond animation using only weights and bones, without any deform keys. This advanced tutorial requires the use of Spine Professional.
To achieve this rotation effect, the skeleton combines the use of perspective rotations, weighted meshes and exact mesh vertex placement by copying and pasting vertices.
You can download the project to follow along, as well as to see the final result here.
To begin the creation of our diamond, we need to import 3 main shapes in Spine: the top as seen from the front
top, the upper square side
upper-side, and the lower triangle side
lower-side. We will later refine the images to add a color gradient and add a separate shimmer image, but to keep things simple as we start, we will only create a new Spine project and import these 3 shapes as illustrated:
After importing these images into Spine, we can start creating the bones to control them.
The final structure of this skeleton is actually simple, it only requires 5 bones to work. The objective is to create a structure that rotates in perspective for the first two sections: the top and middle of the diamond, which can be achieved by using 2 bones for each section, then have a third section at the bottom which is used to control the tail of the diamond.
The first step is to create a section that rotates in perspective, just like the windmill blades in the windmill example project. To achieve this, create two bones that overlap each other, one a child of the other, then parent the slot called
top containing the hexagon image attachment to the child bone so that the bones are in the exact middle of the image. You can ensure this by selecting the
top attachment and, with the parent axis selected, change both the translation values to
The parent bone is the one in charge of scaling the structure, therefore let's call it
top-scale. The child bone is in charge of rotating so its name is going to be
Next, switch to animate mode and create an animation that does a
360° rotation using the bone
top-rotation. To achieve that, set 4 equally distanced keyframes with the rotation values
240° and lastly
0° again to loop the animation.
It's important to create the rotation animation now, because after scaling the parent bone the values of the rotation keyframes will change after being distorted by the scale. If the rotation is done after scaling, using the values above will not produce the desired result.
After the rotation is ready, go back to setup mode and scale the bone
top-scale only vertically. In this example the scale values are set to
0.3, but this amount can be changed to achieve different perspectives. If this is done in animate mode it can simulate changing the angle of view or even changing proportions as in the initial GIF.
For now, let's just duplicate
top-scale so that also its children are duplicated. Place the copy just below and rename the two bones to
middle-rotation, then scale
top-rotation uniformly down a little so that the proportions look more like the top section of a diamond.
The new middle section is not going to be visible in the final diamond, but it's going to be fundamental for the next step.
Now that we have two sections rotating in perspective, we are going to use them as references to position each side of the diamond by copying the vertex positions of the corners and pasting them on the side images so that they will match their positions exactly.
To do so, first convert all the region attachments into meshes, then create the tightest possible meshes for each image so that each vertex is placed on a corner. This is important to avoid gaps between the diamond sides. The mesh trace feature can help to compelete this step very quickly.
For the sake of clarity, different colors have been temporarily applied to the attachments. The result should be similar to the one below.
Once all the meshes are ready, we can start matching the various vertices to create the sides of the diamond, one slice at a time. Select the two bottom middle vertices of the top hexagon image by pressing
cmd on Mac) and, while having the world axis selected, press
cmd+C on Mac) to copy the positions of the two vertices. Next, select the two top vertices from the
upper-side mesh following the same selection direction used to select the previous two vertices, then press
cmd+V on Mac) to paste the vertex positions.
Repeat the process for the two bottom vertices, this time select the two bottom middle vertices of the middle hexagon image, copy the two vertex positions, and paste them on the two bottom vertices of the
To ensure the vertices will follow the rotation of the bones we previously set, we need to bind the mesh to the bones
middle-rotation, then change the weights of the mesh so that the two upper vertices that are touching the top hexagon image are set so that they are influenced
100% by the bone
top-rotation, while the two lowest vertices should be influenced
100% by the bone
The lower triangle side called
lower-side is going to receive the same treatment for the two upper vertices, while for the bottom vertex we can just create a new bone called
lower-point and manually center the bottom vertex to it.
lower-side mesh can then be bound to the bone
middle-rotation influencing the two upper vertices at
100%, and to the bone
lower-point influencing the bottom vertex at
With this, the first slice of the diamond is ready, and if we play the animation we created earlier, this should be the result:
To add another slice to the diamond we need to duplicate the two
lower-side meshes, switch to animate mode, then choose a frame from the timeline so that the side we want to add is clearly visible, then repeat the process of selecting the vertices from the top hexagon, copying and pasting their positions on the duplicated side.
Since the mesh is already bound to the bones we need, this time we are going to press Update bindings to discard the old binding positions for the mesh and replace it with the current positions. However, modifying the vertex positions in animate mode has caused
Auto key to add a deform key. Delete that deform key to restore the correct mesh position after updating the bindings.
Repeat the process of duplicating the two meshes and binding each new side to the correct vertices until all the diamond sides are in position and weighted correctly. After this the middle hexagon image can be discarded as it isn't needed anymore.
The next step consists of adjusting the draw order during the rotation animation. The best time to change the draw order is likely when the new side that should come to the front is about to be revealed. Sometimes this happens on a keyframe, sometimes the exact moment can be captured more easily by holding
shift and dragging the timeline to place the draworder keyframe on a non-integer frame.
The slot colors add the possibility to create a shimmering effect by simply choosing different colors for the same slot during the animation. For example the same side can go from pink, to purple, to green. This is left to your artistic sense!
The placeholder colors and simple textures can also be replaced with more detailed textures and animated slot colors. The images can be repainted and replaced directly in the images folder -- Spine will automatically update the project to use the new images.
The rotating diamond is now complete, but you can add more details like sparkles, or a glow image with additive mode to turn on when the side is facing the viewer to simulate an additional shimmer, as was done here. The glow can even be weighted to the scaling bones of the diamond so that it follows any change of proportions you may decide to add.
It is possible to achieve different proportions by scaling the bones
middle-scale and translating those bones and the
lower-point bone. If done during an animation this can simulate a tilt in the spin, such as in the example below.
This advanced technique can be applied to any geometrical object with flat surfaces, so you can potentially create rotating cubes, pyramids, or even bottles, vases, lamps, chests, gift boxes, stars, books, and so on. We love to see what you create, so don't forget to tag your creations using #madewithspine! Let us know your thoughts on the Spine forum.
June 1st, 2020
A new series of Twitch streams will begin on the 11th of June and continue every Thursday at 4pm CET with our host Erika! You can ask questions live and interact with Erika as she shows off rigging in Spine.
Follow the Esoteric Software Twitch channel to be notified of the start of a stream.
If you can't make it for the stream, don't worry! We'll be uploading the recording on our Twitch streams archive page.
The subject of this cycle of streams is going to be the rigging process of a lovely new mascot designed by Natalia Marcos and Siniša "Sinke" Mataić. Can you guess what it is?
Multi-direction characters have become widely popular in Spine and we've recently added a number of related features to Spine, so we figure it is a good time to make a new series of streams that show the techniques that make the best use of the new features.
Let us know your comments and opinions on the forum.
May 18th, 2020
Weights let you bind the vertices of a mesh to bones. Instead of using free form deformation on individual vertices, you can move vertices by moving the bones they are bound too. Using bones to deform meshes makes it easier to control complex mesh setups and is much more efficient then setting deform keys.
In our previous blog posts on mesh creation tips and a taxonomy of meshes we've discussed the foundations of creating meshes. Here we continue our exploration by discussing workflow tips for assigning weights to your mesh vertices.
Given the same mesh, we can achieve very different results by using different bones and weights to manipulate the vertex positions.
For example this tip shows a cube, weighted so that it pivots around the bone in the front:
Here is the same cube mesh, with the same set of bones, but with the weights reversed so the mesh pivots around the bone in the back of the cube. The reversal is done by inverting the weights and the list of bones the mesh is weighted to.
Here is the same cube mesh again, but with weights set so that the cube pivots around the axis between the vertices in the left and right corners:
In our previous blog posts on meshes, we established simple rules for placing mesh vertices based on the mesh's purpose. We can extend this purpose-based thinking to setting weights. Thankfully, we already did most of the planning when we decided the structure of the mesh.
We've already seen some examples of this purpose-based thinking for weights in the previous section, which considered around which bones the mesh and its vertices should pivot.
What we need to answer when setting weights is the following question: which vertices should be moved by which bone to fulfill the purpose of the mesh?
To make our life easier, we should always strive for simplicity. When setting weights, this means we want to weight vertices to the minimum number of bones necessary for the mesh to fulfill its purpose. The fewer bones we have to deal with to manipulate a mesh, the easier it becomes to animate the mesh.
Here's another example: we can turn our rather static cube into a bendy, jelly cube by first modifying its mesh structure to allow bending, then setting the weights so the bending can be easily controlled by a single bone. Note that this setup only allows us to bend the cube as illustrated in the GIF below. Limiting the cube's "purpose" this way allows the setup to be simple.
By binding meshes in animate mode, you can create advanced setups that add alternative poses which use a different configuration of bones. We've described this process in this blog post, where two different poses of the same wing are bound to the same set of bones.
However, for new users this freedom could be dangerous if used carelessly.
A mesh will remember the position of the bones at the time it was bound to them. A common beginner mistake is to move a bone around, bind a mesh to it, then move the bone back to its original place. Doing this causes the vertices to move when changing the weights, as the bone position is now different from the position it had when we bound the vertices to it.
When binding a mesh in animate mode, the chances of this accidentally happening are even higher, as we tend to move bones around a lot more in animate mode than in setup mode.
Therefore it is almost always best to bind your meshes in setup mode, unless you specifically need to bind a mesh in animate mode to add an alternative pose.
Fortunately, if this kind of little accident happens, it is possible to assign a new binding position to the selected mesh by pressing the update bindings button. This will update the bone positions that the vertices "remember" to the current bone positions, discarding the previous positions.
Weights are set automatically the first time a mesh is bound to bones. To see the effect of our weights, we might be tempted to move the bones around in setup mode. It can be fine to move bones to see how the weights deform and then use undo, but as explained in the previous section, moving the bones in setup mode means the vertices will move when weights are adjusted.
How can we make this process safer? By setting weights directly in animate mode! Create a test animation in which the bones that should deform the mesh are moving, then adjust the weights until you're happy with the results.
This is especially useful when simulating depth or dealing with complex meshes. Seeing your weights in motion makes it so much easier to adjust them compared to setting them while looking at a still pose.
Cmd on Mac) temporarily pauses the animation, making it easier to select the vertices with the weights direct tool.
When testing the effectiveness of the weights assigned to a mesh, always start from the extremes. That is to say, the two most opposite values or positions. We can apply this process to bone positions as well as weights, giving us two different workflows.
The easiest way to set the weights for a mesh is to start by assigning a value of
100% to the vertices that are on the extreme opposite ends of the movement the mesh needs to make. Next, work on getting the vertices in between to balance the mix of weights in an amount that follows the movement planned for the mesh. This applies to nearly all meshes except the simple meshes, which are concatenated instead.
For example, for meshes that are simulating depth, start with the vertices that are the farthest away from the viewer and assign the initial weights of
100% to the bone that will control them. Next, identify the vertices that should be the closest and assign them
100% influence to the bone that will control those. Finally, while playing a test animation, adjust the weights for the vertices in between to achieve the depth effect.
The other way to start from extremes consists of moving the bones controlling the mesh to positions or poses that are beyond what will actually be needed when animating. If a leg should bend, break it a little by going slightly beyond the possible angles. If a face should rotate in space, push it to the extreme limit (which sometimes can look rather comical).
The reason to do this is that at such extremes the fine tuning of the weights becomes easier because the weights that need to be corrected stand out. Also, supporting a greater range of motion can provide the animator with more freedom.
Often multiple passes are needed: after everything looks fine in one direction or extreme position, test the opposite extreme and fix any weights that don't look good. Then place the bones in the previous pose to see if anything went out of place when fixing the other direction.
After everything looks good in all the extremes, the in between poses will likely already look fantastic.
Another way to simplify the process of assigning weights is to find groups of weights that can have all the same weight, or close to it to start with.
Meshes that bend only from a side view make this process quite easy. For example, if you want an arm to retain its shape in the upper part, you will need to select at least 4 vertices and weight them all to the upper arm bone. Then repeat the process for the lower part of the arm. With that out of the way, figuring out the weights for the vertices at the elbow, where the arm bends, is much easier. These can also be selected in pairs of two vertices if the mesh is tubular.
Meshes that simulate depth are a bit trickier. Imagine dividing the mesh into several slices. The slices could be at regular intervals from the part of the mesh that is the most far away toward the part that is the closest to the viewer. Each of these slices is a group of vertices that has the same weights because it's at the same depth from the viewer.
Even if the weights won't have the exact same weights in the end, having a general approximation is still very useful before fine tuning the weights that are not quite right yet.
This principle is similar to parallax scrolling, where groups of images move at different speeds to simulate depth.
When a mesh is bound to more than two bones, it is a good idea to start weighting the mesh from the bone highest in the tree hierarchy and then descending one bone at a time. If the bones are independent, meaning one bone is not parented to the other, then you can simply choose to start from one side of the mesh and progress toward the other side.
Starting from the parent bone lets you to define the general motion first. You can then move on to the child bones to add detail to mesh sections that depend on the parent bone's weights.
For example to recreate the jelly cube, set the weights so it can bend nicely first. Next, add the weights of the the third child bone that controls the top of the cube.
Manually setting weights so that vertices are progressively more influenced by bones can be tedious. The quickest way to make a soft bending mesh is to weight half of its vertices
100% to one bone, and the other half to the other bone, then box select the weights in the middle, and press the Smooth button until the result satisfies you.
A similar result can be achieved by weighting a mesh with fewer vertices, then later adding more vertices to the mesh. Spine will automatically calculate the weights for you based on the surrounding vertices.
When the mesh overlaps with itself, sometimes a part of the image that should be behind is instead drawn on top. When that happens you can fix it by changing the triangle order.
It can be useful to sort the bones a mesh is bound to so that the bone farthest away is the lowest in the list and the closest bone is at the beginning of the list. Assign vertices more weight to the bone that better represents their drawing order to resolve any overlapping issues.
Just like weights, the order of bones in the weights view for a mesh cannot be keyed in an animation. This also means that any adjustments to the triangle order will be reflected in all animations.
Unnecessary weights may be present in your mesh after calculating weights automatically, smoothing, or painting the weights on the mesh. Pruning these weights improves performance, reduces file size, and also makes the weights more manageable.
It may also happen that after setting the perfect weights, several vertices turn out to all have the exact same weights. Removing these extra vertices by editing the mesh and deleting them is another great way to improve performance and making weight adjustments easier.
This whole post is about weights, but what about deform keys? Many new Spine users are tempted to use deform keys to deform their meshes. Deform keys are powerful and have their place, but in most cases using weights is superior for a number of reasons.
First, keying a mesh's deform will key all the vertices together. For example, if your mesh is a head and you use deform keys to animate the ears flapping, you won't be able to come back afterward and animate moving the nose because every key to animate the ears also keyed the nose vertices. You would need to use a straight ahead workflow to animate both the ears and nose together. It is difficult to get this right on your first pass, and it is difficult to go back later and adjust the existing keys. The problem gets worse the more elements you want to animate in the same mesh, like the eyes or mouth.
When using weights, you would assign vertices for the ears and nose to different bones. You then key the bones separately rather than keying the entire mesh.
The other reason to avoid deform keys is that each deform key stores a vertex position for every bone that the vertex is weighted to. If you have 40 deform keys and 100 vertices and each vertex is weighted to 4 bones, those keys will be storing
40 * 100 * 4 =
16,000 vertex positions! This gets worse and worse as you add more meshes and deform keys and can result in your skeleton data being much larger than necessary.
When using weights, you only key the bones and those keys only need to store a little bit of information.
The movement when interpolating between deform keys is always in a straight line, while weights allow vertices to move more dynamically by using bone rotation, scale, or shear, or by having a vertex bound to multiple bones.
Lastly, it's a bit more efficient at runtime to animate bones than it is to apply deform keys. In both cases the vertices are still transformed by the bones, but additional work is required to interpolate between the deform keys.
So when should you use deform keys? Rarely and sparingly! They make sense if you really need to move each vertex separately and it would take many bones to do so with weights. Keep in mind that deform keys can be combined with mesh weights. Sometimes weights provide all the desired deformations, except for a specific pose where they don't quite deform as needed. In that case it can make sense to use a deform key or two to get the mesh to behave exactly as required.
We hope these tips can help you tackle weights and meshes in general and with more confidence. If you haven't already, don't forget to check the two previous blog posts exploring mesh creation tips and a taxonomy of meshes. What would you like to learn about next? We would love to hear your thoughts on the Spine forum.