Welcome to the eighth video of our Animating with Spine tutorial series! This time we cover follow-through and overlapping action. People are deeply familiar with movement in the real world. For your animations to be believable, they need to behave similarly. Careful use of follow-through and overlapping action can tell a lot about your character's physical features.
Here we go through various tips and techniques that are important tools for your animation work. Getting them right can make your animation look more natural and believable.
Use the provided Spine project to do the exercise in the video and hone your animation skills. Share what you did with us on the Spine forum!
We are super happy to announce our new Spine 4.2 release! There are a ton of new features, many of which we've been dreaming about since the first release of Spine, more than 10 years ago. Now they are here!
Let's dive into the highlights!
Physics
Physics in Spine is revolutionary! Spine can now move bones automatically by simulating real world physics. It will save you so much time while also making your animations look better!
Drag her around!
You no longer need to painstakingly animate secondary motion for hair, clothing, and other items. Anything that moves naturally can use physics to move automatically.
Besides saving time, physics also gives you dynamic movement. Physics reacts fluidly and realistically both across animations and from movement of your character through the game world.
PSD import
Spine can now read PSD files directly to bring in your art. This frees you from Adobe Photoshop, allowing you to use any image editor that can save a PSD file.
As a bonus, it is also about 10x faster than the PhotoshopToSpine script!
Pixels mode
When using Spine for pixel art, the new Pixels mode translates region attachments to match screen pixels. This ensures your attachments are not blurry from being off be a fraction of a pixel.
There is also a new Highlight Pixels hotkey that highlights attachments that don't match screen pixels. This makes it easy to see where attachments may be blurry so you can make corrections.
Constraint management
4.2 brings a number of improvements for projects with many constraints:
Duplicating a constraint will ask if you want to duplicate all the bones. This can save a lot of time, for example when setting up limbs.
When multiple constraints are selected you can now change them all at once.
Copy a constraint and paste the settings to another constraint, even in a different skeleton.
Add or remove individual bones from a constraint.
Turn off a constraint via its visibility dot, without changing your mixes.
Weight tools
The new Weld feature matches weights across meshes, effectively welding them together. This allows multiple meshes to deform identically, as if they were a single image.
While great for using multiple meshes seamlessly, weld also saves time by allowing you to apply your existing weights when adding clothing, facial expressions, clipping attachments, etc.
Lastly, you can now copy and paste weights to other vertices, even on other meshes.
Looping curves
The curve handles of the first and last keys of looping animations are now synchronized. Sometimes it's the small things that save you a lot of time!
Folders
Draw order folders allow organizing your slots for large skeletons. You can adjust the draw order by dragging a folder rather than many individual slots.
Constraints folders make complex skeletons more manageable. Middle click a folder to select all the children.
Root motion
Our spine-unity runtime can perform root motion for you!
Normally you animate a walk cycle in-place, then code at runtime moves it at the right speed through the game world. When the movement is complex, like a shuffling zombie, it's very difficult for code to match the animation.
With root motion, the walk cycle is animated with movement. At runtime we remove the movement from the animation and apply it to the game world position. The resulting movement through the game world is a perfect match to the animation.
Even more advanced, our root motion delta compensation feature allows you to seamlessly adjust the distance of a jump or similar animation. This way the animator can carefully design the movement in Spine and the programmer still has control over how far the animation actually moves in the game world.
New Runtimes
Since our 4.1 release we have added a ton of new runtimes!
With spine-godot, we've implemented a runtime for the most popular Open Source game engine available.
For folks who favor a more direct approach, we've created spine-sdl, which can be used with either our spine-c or spine-cpp runtimes.
We have started our foray into mobile apps with spine-flutter. There will be more to come soon!
Our spine-phaser runtime is a complete replacement of the old Phaser Spine Plugin. Providing a Spine runtime for Phaser ourselves ensures timely updates and reduces the burden on the Phaser team.
More recently, we have added spine-haxe to our arsenal. It can be used with Starling on top of OpenFL/Lime. We are planning to also support other frameworks on top of OpenFL, such as HaxeFlixel.
Our final entry in the list of new runtimes is spine-pixi, an official Spine runtime for PixiJS. As with spine-phaser, we want to ensure our users get timely updates with official support.
These runtimes are production ready and have a plethora of code examples to get you started. We are currently working on completing the respective documentation, which will be ready in the coming weeks.
Unreal Engine 5.3 support
In Unreal Engine 5.3 Epic has changed the way assets are handled. It is no longer possible to have two assets with the same name but different types in the same folder.
Given that, you now need to ensure that your skeleton data files (.skel and .json) and atlas files have a different prefix. For example, skeleton-data.skel and skeleton.atlas. Alternatively, you can put your skeleton data and atlas files into separate folders.
Also, the Unreal does not allow spine-ue proper access to assets created in older Unreal Engine versions. This means we can not provide an automated upgrade path. If you want to migrate projects to Unreal Engine 5.3, you have to manually recreate and rewire your assets.
Unity
In Unity, by default any Transform movement is seamlessly integrated with the skeleton's physics constraints. Just move the skeleton around and physics responds appropriately. If the default settings fall short, a small change to the Physics Inheritance settings will do the trick. Don't miss the new Physics Constraints example scene and be sure to give those skeletons a good shake.
The SkeletonGraphic component has also received new features. You can set the new Layout Scale Mode to automatically fit the skeleton to its RectTransform bounds. Also, have you ever struggled with SkeletonGraphic displaying incorrectly or finding the correct Inspector and material settings? Those days are over, thanks to the new auto detect buttons! There is even a Detect Material button to automatically assign the correct material from our newly expanded materials set.
No release would be complete without shader improvements. We now support Tint Black with all Spine URP and Spine/Sprite shaders and have added URP blend mode shaders to round out this update.
Other runtime changes
All runtimes support all the new editor features and are ready for production! Please refer to the Spine Runtimes changelog for game engine and language specific changes.
With the additions of physics, we had to change a few APIs:
Skeleton.updateWorldTransform() now takes an additional physics parameter to control when physics is updated and applied. In most cases you'll want to use Physics.update.
To drive the physics simulation, the physics code needs to know how much time has passed. This information is stored in each Skeleton. If your frame time has advanced, make sure to inform the Skeleton by calling Skeleton.update(deltaTime).
We have renamed TransformMode to Inherit. Unless you manually set transform modes, this change should not affect your code base.
We have renamed TrackEntry.attachmentThreshold to TrackEntry.mixAttachmentThreshold and TrackEntry.drawOrderThreshold to TrackEntry.mixDrawOrderThreshold.
Besides these API changes, you will also have to re-export your skeletons with Spine editor 4.2 if you want to use the Spine Runtimes 4.2. See our Spine Versioning Guide for more information.
Up next
We are very happy with Spine 4.2! The new features are easy to use but very powerful. Physics is a game changer, saving you tons of time while also improving your animation with dynamic movement.
After a big release like this, we like to do a smaller release with refinements and quality of life improvements. In 4.3 we will focus on streamlining your workflows. The goal is to save you time by reducing the effort needed to perform common tasks.
Thanks to everyone in our community who reported issues, tested the beta, and gave their suggestions and feedback to help shape our new features. Your input is invaluable!
We've just released Spine 4.2.10-beta where we've added the ability for the Spine editor to process PSDs directly. This is great for many reasons:
You are no longer forced to use Photoshop -- use any image editor that can save a PSD file.
All the tags from the PhotoshopToSpine script are supported.
It is much faster! On a large PSD (200MB, 215 layers) it finishes in about 25% of the time (6 seconds versus 23) compared to the PhotoshopToSpine script.
Process the PSD and import it into Spine in one step.
To try it out, go to Import Data and choose a PSD file:
Use our new shell scripts to export all your projects at once! The scripts search for .spine project files and export each project found. Each project can use different export settings by placing an export settings file next to the project file.
Using a script to export has many advantages:
Export any number of project files all at once.
Your exports always use the correct settings. No need to rely on animators to use the right settings each time.
Your software's build process can run the export scripts, ensuring every build always has the latest exports. Animators don't need to remember to perform exports after every change to the project files.
When updating to a newer Spine version, all your projects must be exported again. When you have export scripts setup, this is very easy!
When you open the script with a text editor you'll find a Customization Section at the top. Here is an excerpt from spine-export.bat (spine-export.sh is very similar):
The first three settings should be reviewed before running the script:
SPINE_EXE The path to the Spine executable file. If Spine cannot be found here, the script will look in other common installation locations.
VERSION The version of the Spine editor that to use for performing the exports. Keeping your Spine editor and runtime versions that same is very important.
DEFAULT_EXPORT The script looks for an export settings JSON file in the same folder as the Spine project. If that is not found, the export settings specified here are used. There are 4 shortcuts for common default settings: json, json+pack, binary, or binary+pack. Alternatively, you can specify a path to an export settings file (see below for more about that).
On macOS or Linux, before running spine-export.sh you must first grant it the execute permission. Open Terminal, navigate to the directory where the script is located, then grant execute permission with this command:
chmod +xspine-export.sh
To run the script, specify ./spine-export.sh and the path to the directory containing the Spine projects you wish to export. For example:
Open the script file with a text editor and change the value of DEFAULT_EXPORT to the path of your .export.json file. For example:
DEFAULT_EXPORT=/path/to/default.export.json
These settings will be used if no .export.json file is found next to a project file.
Note that the exported files will be output using DEFAULT_OUTPUT_DIR in the Customization Section, not the output path in the default .export.json file.
To export a Spine project with different settings, prepare an .export.json file with the settings and save it in the same folder as the Spine project. For example, the filesystem hierarchy could look like this:
To export a project multiple times with different export settings, prepare and include that many .export.json files. For example, to export the skeleton data both in binary format and as a PNG sequence, your filesystem hierarchy could look like this:
You are welcome to write your own scripts using Spine's command line interface or modify our scripts to meet your needs. We have written comments in the script to describe everything it does and the README file goes into greater detail about how it works.
Have you found this tutorial helpful? We would love to hear your feedback in the Spine forum!
