Slot Color view

March 13th, 2015

In our ongoing effort to improve productivity through utility views, we're happy to announce that Spine now has a Slot Color view. This makes it fast and easy to change the color of an attachment, without needing to use the modal slot color dialog and the extra clicks that entails.

When sized smaller, some of the controls are hidden:

The Slot Color view shows the slot color for any selected attachment, so now you can just select any number of attachments and instantly set the color of the slot for each one. Complete documentation is here.

Discuss this post on the Spine forum.

Outline view

March 7th, 2015

Spine has gotten a new view! The Outline view shows the skeletons in your project similar to the editor area, except without drawing tools or the selection. This gives you a clear view of your whole skeleton, even if you are working with the editor area zoomed in. It can also be used to visualize the skeleton when editing mesh UVs. Finally, you can click in the Outline view to quickly pan the editor area view. Brief documentation is here.

Spine's modular view system makes it easy for us to add more views and tools. We have lots planned, so expect more soon!

Discuss this post on the Spine forum.

Performance metrics

March 1st, 2015

Performance is interesting because it very often doesn't matter. Even the worst application running on the most terrible hardware doesn't need optimizations as long as the performance is acceptable. The rule is: if improving performance would not be noticeable to the player, then any time spent improving performance is a complete waste. That time is always better spent on things noticeable to the player.

This doesn't mean performance should be ignored during development, only that minimal performance considerations should be made as preemptive attempts to avoid performance problems. It's very easy to go too far and waste time, especially when so many variables are involved:

  • what hardware the application is running on,
  • everything done by the application and game toolkit besides rendering Spine animations,
  • how the game toolkit and Spine runtime perform rendering,
  • how many skeletons are rendered,
  • how those skeletons are configured,
  • how many pixels are drawn,
  • and much more.

When designing Spine animations, ideally animators take all of this into account and only deliver assets that perform well. In reality, animators tend to feel very alone in a big universe and often build animations without considering how it impacts runtime rendering.

To help with this, we've added the Metrics view:

This shows a number of metrics that can help give an idea of how expensive skeletons will be to render at runtime, both for the CPU and GPU. You can read more about each individual metric on the Metrics page of the Spine User Guide, but I'll mention a few of the most important numbers here.

The number of bones, constraints, timelines, and vertex transforms all contribute to CPU usage. Vertex transforms tend to be the highest, especially when using mesh weights. Meshes should use the lowest number of vertices to deform the mesh as required.

Area gives some indication of how many pixels are drawn, assuming the skeletons are drawn at full size. This can help determine how the skeletons impact the fill rate.

Even with the Metrics view, performance relies on so many variables that it isn't possible to generalize about which numbers are too high. You will need to perform your own tests using your actual skeletons on a variety of hardware to get an idea of the limits in your environment. Even then, if you aren't pushing the CPU or GPU to its limits, then there is no need to waste time stressing about performance or to sacrifice the quality of your animations.

Discuss this post on the Spine forum.

OlderNewer