We're super excited to announce the expansion of our little team here at Esoteric Software! Erika Inzitari has joined our efforts. For this intro, we switch things up a little, interview style.
Welcome to the team, Erika! Tell us a little bit about yourself and your background
I'm a girl who happens to like Spine very much! Previously, I went to an art academy, later I enrolled in a communication design curriculum at university. But what I really like is the idea of motion and transformation! At the age of 3, I decided I wanted to do something involving animation when I grow up. Watching movies on VHS, my favorite parts would be all the moments involving magic: a mouse turning into a horse, or a monkey into an elephant, anything was possible! I also was a lucky child as my farther taught me how to use Windows when I was 4 years old. Since I didn't have many games, I'd play around with the .exe files in the system32 folder, developing an affinity for computers (and not destroying any in the process). Those were the days! This eventually led me to look into game development as well. I've since joined a few game jams and have worked with gaming companies as an animator/rigger. It's my dream to create an interactive children's story one day, and take a stab at animated films & cartoons.
What brought you to Spine?
This is actually a bit of an awkward story. I first saw Spine when my partner researched animation tools and stated that Spine was "THE BEST TOOL EVER (tm)". I watched him use it with suspicious eyes, opposing his every cheerful comment about Spine just for the sake of opposing, saying I don't like the fact that the animations were so fluid and puppet-like, and that the price was a bit too high to spend on software I didn't know and I wasn't sure was usable for me.
Sometime later, he started talking about Spine again, pushing it as the perfect tool for what I wanted to do. I bit the bullet and started watching videos about Spine, reading up on features, checking out comparisons written by other people, checking out (amazing) works of art others have achieved using Spine. Not wanting to give him the satisfaction of being right too quickly, I said, "OK, maybe I can give this a try". I started playing around with it on the side while working for a gaming company who hadn't yet adopted Spine. At my next gig, Spine was already a requirement, so I bought me that sweet sweet Spine Professional and got to work.
I invaded the Spine forums with my first questions. Not expecting a quick answer, I checked back 2 weeks later. To my surprise, my questions had been answered immediately! This made me feel so bad, I started checking the forums daily (because even with my amazing computer skills, I couldn't find the subscribe button, which I only discovered 2 years later...). Once I knew enough, I started returning the favor, answering other people's questions, since everyone was super kind. Suddenly I found myself being very passionate about the software and especially the community.
Which is when my partner started to get his revenge... He'd nag me once in a while with a well placed, "Oh, Spine again? Wasn't that that software with too fluid and puppet-like animations?". (I swear this happened again yesterday evening!).
I couldn't help but tell him I was totally wrong, and that I'm happy he proved me wrong! I fell completely in love with Spine and think it's the best software around for 2D animations in games.
What's your role on the Spine team?
As an animator and Spine connoisseur, my role is to assist people with their Spine Editor related questions. I love some good problem solving, especially if it helps others! I'll also be in charge of a workflow-oriented tutorial series I'll be in charge of. I hope you'll find it useful!
Question from the audience. What ingredients were used to summon you from your magical realm?
10grams of Rooibos, Vanilla, a couple dog hairs, pumpkin flowers, chocolates aaaand fried potatoes.
Hot on the heels of our recent 3.6 release, we're happy to announce the release of Spine 3.7.00-beta. This release focuses on audio directly within the editor, to make synchronizing animations to your audio clips easier.
The first difference you'll notice in this beta release is the addition of an audio node in the hierarchy view.
The new audio node works similarly to the images node. All audio files found in the specified path will be listed under the audio node (which is only available in setup mode). Spine currently supports the WAV, MP3, and OGG audio formats.
Once you've placed an audio file in the (sub-)folder the audio node's path points to, it will show up under the audio node. Selecting the audio file will allow you to create a new event from the audio file.
You can also drag an audio file onto an existing event.
Events now have an additional field called "Audio path", indicating which audio file they are associated with. When you key an event with an audio path set, the dopesheet will show the length of the audio file and, in future betas, the audio waveform. When you playback the animation, the audio will start playing as soon as the event key is triggered.
Note that the duration indicator for the audio file appears in the timeline only once the audio file has been loaded.
We'll expand on the audio feature in future 3.7-beta releases. The next step is to also display waveforms for each audio file in the timeline, which will help with lining up your audio and animations.
The audio feature is currently editor-only. At runtime, audio is handled as before: register an event handler with AnimationState, react to events and playback the audio you want for a specific event based on the event's data: its name, string, int, float, or audio path fields.
For discussion, feedback, and bug reports, please post on the forum thread for this release!
After a few months of work, we've finally completed Spine 3.6! The focus was mainly on things that have been bugging both you and us for a while, including hundreds of small improvements to existing features and bug fixes. On top of that, we managed to add a few great new major features, see below!
For a full run-down, check out the editor changelog, as well as our brand new runtimes changelog. All the runtimes are already up to date and work with 3.6.
While the Spine Runtimes faithfully reproduce your animations in your games as you see them in the editor, it was previously only possible to review transitions in-game. In 3.6, you can now preview your animations using many of the same controls that are available to you at runtime, including modifying your setup pose and animations while the preview is running! The usefulness of seeing your animation at the same time you are editing that animation cannot be overstated.
The new clipping feature lets you define a polygonal area, similar to a bounding box attachment, that will mask other slots in the draw order. The clipping area can be any concave polygon without holes and self-intersection. You can also animate the clipping area vertices. Only one clipping area can be active at a time.
Clipping is implemented CPU-side in all runtimes, as most engines do not support direct stencil buffer access or masking. Clipping can be a very expensive operation, especially if you use dense mesh attachments. Always check the performance of your clipped animations on your target platforms.
This makes for more powerful tinting so you get more out of your images. You can do some nice effects, like the Super Mario invincibility star flashing, solid color outlines, inverted colors, and more. It can also look nice when using additive, screen, or multiply blend modes.
Tint black is supported by all runtimes except spine-ts Canvas, spine-corona and spine-sfml due to API limitations of the respective framework/engine.
Modifying vertices in a dense mesh attachment is now considerably easier with our improved mesh manipulation tools. You can now select multiple vertices through soft selection and then scale, translate and rotate the selected vertices as a group! Feathered soft selections will apply your transforms only partially.
In tandem with our new mesh manipulation tools, we've also introduced weight painting tools. The weight painting tools come with feathered brush support and different weighting modes, complimenting the existing automatic and manual weighting functionality.
This new type of attachment is a point in space and a rotation, which is transformed by parent bones like you'd expect. It can be used to spawn particles or do anything else that involves a position and/or rotation. Point attachments have one advantage over bones: a point attachment can go in a skin, so the position and rotation can change for different skins. For example, different guns may shoot from different positions.
Many workflows involve working in a handful of directories. We've introduced new file dialogs that show you recently opened project files and often used directories. You can explicitly favorite a file or folder for it to show up at the top of the list. Right clicking an entry will remove it from the list. The filter box allows you to quickly filter for files by parts of their name. We've also added a few hot keys to make your file browsing even more efficient. Pressing enter will chose the most recent file or folder, pressing spacebar will immediately open the OS file dialog if you can't find the file or folder you want in your recently used lists.
AnimationState is a part of the Spine Runtimes which controls applying and queuing animations, crossfading between animations, and layering animations on top of each other. With the 3.6 release, we've vastly improved on the previous implementation, ensuring that transitions between queued animations are always smooth, without bones snapping into place. You can read more about the inner workings in our blog post AnimationState: multiple mixing without dipping.
Alongside the improvements to the Spine editor, we've also put a lot of work into making the official Spine Runtimes better!
We've added support for clipping and point attachments to all runtimes. Tint black is supported in all runtimes except spine-sfml, spine-ts canvas, and spine-corona. The tint black feature requires additional vertex attributes which these engines currently do not support.
The libGDX runtime is now also released to Maven Central. The version string is composed of the latest Spine Editor version the runtime supports, plus a patch version. The latest beta version is also continuously built and deployed to the SonaType snapshot repository.
The Cocos2d-X and Cocos2d-ObjC runtimes have seen performance gains of up to 15% by removing all per-frame allocations. We've completely rewritten the rendering infrastructure and also added mesh debug rendering support!
The Unreal Engine 4 runtime is now using the excellent RuntimeMeshComponent instead of the built-in ProceduralMeshComponent. That also means that you have to copy over the RuntimeMeshComponent plugin to your project's Plugins folder! This change was required to implement the tint black feature, for which we need custom vertex attributes. We've also ensured that the runtime works with the latest Unreal Engine 4.16.1 release. Please note that Unreal Engine 4.16 had a regression which made it impossible to compile plain .c files with MSVC++. We've submitted a PR for this issue which is now in 4.16.1!
spine-unity now supports tint black via the UV2 and UV3 vertex buffers and special tint black shaders. This capability is now shared across all Spine rendering components via the new single Spine.Unity.MeshGenerator class. You can also set the initial flip state of your skeleton in the inspector. On the Unity Editor side, we've added several improvements and tools. The biggest change you'll notice is that [SpineAttributes] now show icons in their inspector dropdown drawers so your inspectors are more readable at a glance! They can also use sibling fields as data fields so you can limit your scope within your custom serializable structs/classes (previously, it only used fields your Component class). Two new windows were also added: SkeletonDebugWindow for seeing invisible skeleton parts in Scene View and runtime debugging skeleton states, and SkeletonBakingWindow for accessing specialized baking features.
Both the spine-ts WebGL and Widget backends now support WebGL context loss recovery out of the box! The feature is on by default. We've also increased performance of the WebGL and Widget backends considerably by being smarter about what data we move to the GPU and when.
The spine-ts Canvas backend now supports shear and alpha tinting. Full color tinting is sadly not supported as the Canvas API does not expose this feature.
For a full list of changes to all runtime, check out our new runtime CHANGELOG, which details API breakage, additions, as well as new features and improvements!
Up until this release, the master branch on our spine-runtimes GitHub repository was the latest stable release you should use. Starting today, we are removing the master branch and will henceforth use branches named after major Spine versions. The latest stable version will be the default branch on GitHub, e.g. 3.6 for the current release, while development will happen in the beta branch of the next version, e.g. 3.7-beta.
If you have scripts of continuous integration builds that rely on master being the default branch, now would be a good time to update them and explicitly specify your Spine Runtime version!
With our kitchen sink release out of the way, we plan on shorter release cycles corresponding to single big features. Our roadmap for 3.7 will bring audio support, which will be available as a beta version surprisingly soon. On the runtime side, we will focus on documentation, samples, and performance improvements, as well as adding support for more engines.
Thanks to all of our users who reported issues, tested the beta, and proposed new features. We couldn't do it without you!
Spine 3.6.22-beta has a new feature: the Preview view. This allows you to play animations with mixing (crossfading) and tracks (layers), similar to the Skeleton Viewer. However, since you are previewing inside Spine, you can edit an animation while previewing it which is really, really neat!
It's currently a work in progress and has some known issues that we are working on (such as images that aren't loaded), but we thought we might as well get it in the beta early, especially since it's so useful. We'll have more beta releases soon to fix it up, then 3.6 will be released as non-beta. We've already started on audio support for 3.7, which we intend to release in a much shorter time frame than 3.6.
