3.5.00-beta released

September 16th, 2016

Today we are happy to have released Spine version 3.5.00-beta!

First beta release

This is our first beta release. The "beta" tag means that one or more of the officially supported runtimes have not yet been updated to work with the editor release, otherwise it is just as stable as a normal release.

By default, your Spine installation won't automatically update to a beta version when set to use the "Latest" version. Beta releases allow us to do editor updates without everyone being upset that the runtimes are not yet updated. If you want to use the latest beta, you'll have to check the beta checkbox in your Spine settings:

After 3.4.02, if you always use a non-beta release then you can be certain that your exports will work in an official runtime. Here are a few reasons you may want to give up that guarantee and use a beta release:

• You are exporting images or video, so lacking runtime support doesn't matter to you at all.
• You want to try out our fancy new features ASAP. You can always go back to any older Spine version, just be careful not to save your projects with a newer version, since older Spine versions won't be able to open them.
• You know the runtime you are using has already been updated to work with the beta editor version. Some runtimes will be updated before others and we won't do a non-beta release until all runtimes are updated. Each runtime's README on GitHub specifies the most recent Spine version it works with.
• You want to animate with the latest version and are OK with waiting until the runtimes have been updated.

Just keep in mind that if you update to a beta release, do a bunch of work, and then are upset that the runtimes have not yet been updated... well, we will find sympathy difficult!

Runtime status

Before going over a few new features, let's talk about the current status of the runtimes. We've been making fantastic progress -- all of the runtimes are updated to work with 3.4.02 except the Lua family of runtimes. We are nearly finished with spine-lua and the rest will come very soon after. Some runtimes have seen massive improvements, especially spine-js which has become spine-ts as described in our last blog post. To really see the power of spine-ts, be sure to check out our new demos page!

As soon as the Lua family of runtimes are updated to 3.4.02, we will start a new round of updates to bring them all up to version 3.5. We have greatly beefed up our resources for keeping the runtimes up to date, so in the future they will not lag very far behind the editor updates.

Now let's move on to what is new in 3.5.00!

Constraint order

The order constraints are applied can be specified by dragging constraints in the tree, which enables all kinds of fancy rigging. Previously the order was fixed: IK, then transform constraints, then paths. By default Spine guesses at a reasonable order, but you can customize it for full control. For example, you might have a transform constraint set the position of an IK bone, then apply IK, then apply another transform constraint. Constraint order will also be crucial as we add more constraints in the future.

FPS

The frames per second for playback can now be specified on the Playback view. While the default of 30 frames per second is probably fine for most, some animators have an intuitive sense of how many frames a certain movement to take when animating at 12 or 24 frames per second. Changing the FPS can also be useful when animating fast movement. You can always hold shift to set keys between whole number frames, but it may be more comfortable to change the FPS higher than default, for example to 60. This way you still get snapping to whole number frames.

Changing the FPS affects the speed of the animations at runtime and the setting is for the entire project. Changing the FPS does not change the frames for existing keys, so your animations will run slower or faster. This means you should set the FPS before you start animating.

Disabling scale

We weren't happy with how unchecking Inherit scale worked previously. In some situations where negative scale is involved to flip a character, rotating a parent bone would cause a child bone to appear to rotate in the opposite direction. Due to some mathematical breakthroughs, we now have a much more robust "disable inherit scale" feature which works in every scenario.

Unfortunately disabling inherit scale does work slightly differently than it used to: nonuniform scale (different X and Y scale) on a parent bone still affects the rotation of the bone which has scale disabled. This makes sense in practice and it's unlikely to cause problems with existing projects, but we're mentioning it for full disclosure. If this behavior is not what you want, consider using a transform constraint to take the parent bone's position and rotation but not scale.

Disabling reflection

Along with the new disable inherit scale comes a new feature: the ability to disable scale but not reflection. Reflection means the use of negative scale to reflect or "flip" a bone to the other side of one of its axes. Now when you disable scale you can choose to still inherit reflection, so the bone doesn't scale when its parents are scaled, but still flips when its parents are scaled negatively.

Discuss this post on the Spine forum.