Spine 3.4 released - Shearing, Paths, and much more!
July 12th, 2016
The past couple of months have been a whirlwind of activity here at Esoteric Software.
We are very happy to have Mario Zechner join the Spine team. You may know him as one of the founders of libGDX. We expect great things (no pressure). Everyone, welcome Mario!
Spine 3.3 and 3.4 are chocked full of bug fixes and new editor niceties, as well as big new features to make your work easier and your animations even more awesome. For a full list of changes, check out the changelog. Here's an overview of the most important changes!
Improved Transform Constraint
Transform constraints can now copy the world rotation, translation, scale, and/or shear from one bone to any number of other bones. It may be a bit tricky at first to recognize when this would be useful, but it enables a lot of fancy rigging and neat tricks. Among many other things, you can save time by animating one bone and have many other bones also animate, or you can make a bone appear to be re-parented to another bone, eg for taking off a hat, drawing a weapon, or throwing something into the air.
Also note the shear on spineboy's head!
Shear is a new tool that allows the angle between the X and Y axes to be adjusted directly. This causes child bones and attachments to be skewed. Similar to scale, shear can be used as a kind of squash and stretch. It's great for Spine Essential users to get more interesting deformations without using meshes.
Paths and Path Constraints
Paths allow you to draw curves (a Bézier spline), then have bones follow the curves. We provide many options and modes that make this very powerful. Bone spacing and position key be keyed, so bones can be animated along the path. Bones can be scaled automatically, making very bendy paths possible. Similar to meshes, paths can be deformed and keyed manually, as well as be weighted to bones. This enables using a few bones to control the path, then having many bones constrained to the path, then a mesh can be weighted to the many bones. This and other setups make for very powerful and easy to use rigging.
We have new example projects showing off path features. See the vine, tank, and stretchyman examples in your Spine installation folder (you may need to download and reinstall Spine). While we are working on proper documentation, this video covers the example projects and new features.
With Mario joining, there has been a lot of movement on the runtime side of Spine, with much more to come.
All runtimes based on spine-c, which include spine-sfml, spine-cocos2dx and spine-cocos2D-objc are now fully compatible with Spine 3.4. We've also added CMake builds to make running the demos as simple as possible, including downloading dependencies and setting up IDE projects. Check out the README.md files in each respective runtime directory.
We have deprecated support for Cocos2D-X v2, as this version is no longer maintained upstream. Similarly, we have deprecated support for Cocos2D-iPhone v2, now called Cocos2D-ObjC. In both cases, the latest Spine runtimes will only support the 3.x versions of Cocos2D-X and Cocos2D-ObjC going forward. We have created branches for both Cocos2D-X v2 and Cocos2D-ObjC v2 for those among you that are still working on projects using those versions. Note that we will not backport the 3.3 and 3.4 changes to those unmaintained versions of Cocos2D-X and Cocos2D-ObjC.
spine-csharp, spine-unity, spine-xna and spine-monogame have also been updated to Spine 3.4.
We are now in full swing bringing the other runtimes up to Spine 3.4. We have already started work on spine-as3/Flash and spine-starling. We will deprecate the spine-starling runtime compatible with Starling 1.x in favor of our brand new Starling 2.0 compatible runtime. You can see the progress on the as3-update-3.3.0 branch.
New Runtime Development Model
We have introduced a new development model for the runtimes. The master branch always contain the latest runtime versions. All new development is done on the dev branch. Modifications on this branch will usually be limited to adding new features to the Spine libGDX runtime, which is the reference implementation used by the editor. Once the reference implementation is complete, we open a new branch for each of the other runtimes, where we port the reference implementation changes. Finally, we'll merge the dev branch as well as the other runtime branches back to master, tag the repository with the Spine version the runtimes support, and release the new Spine update. Also, all commits are now tagged with prefixes corresponding to the runtime(s) the changes were made to. This will more easily allow you to see what is going on with a specific runtime.
This new development model was introduced to fix one of the major pain points our users have: versioning. The next piece of the puzzle are beta versions.
Since the Spine 3.0 release, we have pushed editor updates fairly frequently. Some new features also require updates to the runtimes, eg due to a change in the export format or the addition of a new feature like paths. At the time of a new Spine release, only the Spine libGDX runtime is guaranteed to be compatible with the exported data. Updates to the other runtimes come some time after a new Spine release.
The intention of this release model was to get the latest Spine features into your users hands as early as possible. However, this has also resulted in some of our users struggling with versioning. While we have written an extensive guide on versioning, we feel the need to provide a better solution.
Starting with Spine 3.4, you can opt-in to our beta releases. Spine beta releases let you test and give feedback on the features that will be included in the next Spine release. During the beta phase of a new Spine release, only the libGDX runtime is guaranteed to be up to date.
Once all new features have been finalized and all runtimes have been updated, we will push out a new Spine release. This guarantees that all standard releases of Spine will have up to date runtimes, minimizing versioning troubles.
If you need runtime support, please do not opt-in to beta updates. Instead, wait until a standard Spine release where you can be sure your exports work with all official runtimes. If you want the latest features and either you don't need runtime support (eg you are exporting images or video) or you know that the runtime you are using has been updated for that beta version, then opting in to beta updates makes sense.
You can always switch between the beta releases and standard releases in Spine's settings dialog. Feel free to try out new features in beta updates, just be careful not to save your projects with the beta version if runtime support is not yet available. To help with this, we now show a warning the first time you save a project with a newer version.
New Issue Management
Many moons ago, we created Trello boards for you to track our progress and provide us with feedback. With our community growing constantly and our development model changing, we have outgrown Trello.
Going forward, we will use GitHub to get your feedback and bug reports. This has many benefits for both you and us. On your end, you can enable notifications on specific issues you are interested in. Notifications will tell you about new comments from other users or us, as well as development progress. On our end, GitHub issues fit cleanly into our development model, making it easier for us to react to user feedback like feature requests and bug reports.
We have setup two repositories on which you can file feature requests as well as bug reports. Anything related to the Spine editor should be reported on the spine-editor repository. Bugs and feature requests for a specific runtime should be reported on the spine-runtimes repository.
As a first step, you need to sign up with GitHub. Before you file a new issue, search the existing issues. Chances are someone else already filed an issue that fits your needs. When you file an issue against the spine-runtime repository, please use a prefix that indicates the runtime that it targets:
[unity] for the Unity runtime,
[starling] for the Starling runtime, etc.
All cards from Trello have been transferred to GitHub. If you want to see a nice overview for each repository, check out our new roadmap page. This gives you a good sense of what we are working on at the moment (minus the secret sauce).
Nothing warms our heart more than seeing your Spine creations. Our showcase subforum has been the go to place to see what Spine users are working on. While this is great, it is limited to our forum community.
As devious marketing geniuses, we have devised a plan that will bring your art as well as Spine to the world. In addition to posting on the showcase subforum, we'd also love to see you post your progress pics or fully finished animations on social media, eg Twitter or Facebook. To make it easy for everyone to find your oeuvres, tag your tweets, posts, instagrams with the hashtag #madewithspine.
We are monitoring all kinds of social media outlets for that hashtag and will happily promote your art. We are also putting together a dedicated showcase page directly on esotericsoftware.com that will display a live stream of all things #madewithspine. More on that in a future update.
소울아크(SOUL ARK) 소개 영상 https://t.co/BP1Cs7O70y #소울아크 #soulark #madewithspine— dugy(태오아빠) (@dugy_) July 6, 2016
We are hard at work bringing all runtimes up to the latest Spine version, spine-lua and spine-corona included. On the editor front, we have a few secret things brewing that we hope to release to you in beta form soon. We are also in the process of going through the backlog of bugs and feature requests you have filed.
Get the latest Spine release to play around with shearing, improved transform constraints and paths, sign up for GitHub to give feedback and report issues, and post your stuff on social media using the #madewithspine hashtag.
Happy animating! Your Spine Team
Discuss this post on the Spine forum.