Congratulations! The changelog is packed full.

I've got a bunch of these coming up, but I'll just use this one thread for them from now on.

Here's the intro episode.

Workflow:

• Spine used for the main character rig with PNG sequence export.
• The facial animation (lips, expressions) are handled in a custom web-based tool I wrote.
• Comping and other animation is in After Effects.

Enjoy!

The latest AtB cartoon. I'm on a mission to make one a week...

As mentioned before, the workflow is a mix of Spine and After Effects animation, with the main Jamie character being mostly Spine-animated.

For this cartoon, I had some smaller character animations I thought I could do more quickly in AE, but... Nope. It's a major pain to fiddle with hiearchies of layers in AE that define a rig. Also, audio scrubbing after SO MANY YEARS is still not available in AE.

So my lesson here is to move animation authoring with more than a few moving parts or significant audio timing into Spine.

Learning from last week’s hassles with complicated rigs in After Effects, I decided to put all the animation for the scene in Spine with the exception of some pans and the credits screen. It worked much more easily.

The latest cartoon. This one has six character rigs in it, and generally, I put a lot more time into it than the previous episodes.

One feature of Spine I started using here was clipping. The problem has come up a few times where some prop or part of the scenery is behind some, but not all of the characters slots The most common case of this for me is when characters sit at a table. Here I want the arms/upper body in front of the table, and the legs/lower body behind (underneath) the table. Or in the still image above, you can see the guy behind the right arm of the chair he is sitting on, but if he lowers his arm, it should go in front of the right chair arm.

Previously, I included the table/prop inside of the character skeleton. But this meant a lot of special-case skeletons and extra images in the atlas. So I like the clipping solution better. I just put the character skeleton in front of the table, and clip out the lower body.

Love her! She really keeps that hand-illustrated look throughout her movements.

Ah, makes sense. 3.7 has just been useful for so long that I forget it's a beta.

I think there is a documentation "bug".

In 3.7 runtime for WebGL, "MixPose" is not defined. Looking through the runtime source, I think it is now "MixBlend" that is defined and exported. At least, I was able to call Timeline.apply() passing spine.MixBlend values. The docs here ( MixPose ) still say "MixPose".

No big deal for me. Just trying to help out.

Very cool. I might reuse some ideas from your best practices doc in the future. Thanks for sharing.

Andre, I read through this with much interest. It seems like an inevitable document one would need with a team of more than a few people. I think its level of detail is good - not too vague, not too bureaucratic. If I were joining your team as a newbie, I could probably figure out how to make rigs the expected way without much trouble.

If you don’t mind, What is your team structure? E.g. how many developers, artists, animators?

The thing I'm happy about today is getting the outlines around the arms to work how I wanted. There are separate slots/attachments for the black outlines.

This is the closest I'll get to participating in Inktober.

I don't know if this works, but maybe worth a quick try...

In your frame render code, first apply the active animation with delta, then call setAttachment and apply the skeleton. My thinking is that the second action should overwrite the changes made by the first. Some example code:

const state = ... /* your AnimationState variable used earlier to play animation. */
const skeleton = /* The skeleton affected by the animation. */
const slot = ... /* The slot of your skeleton that will have its attachment set. */
state.update(delta);
slot.setAttachment(attachment);
state.apply(skeleton);
skeleton.updateWorldTransform();

Nate or somebody more knowledgable could give you a better answer, I'm sure. But maybe it helps.

My first thought is... why would you use Spine to do that? Because you could accomplish it so much more easily in a 3D engine like Unity, and put the sprites on top of a true 3D background.

But it’s still a cool idea.

If I were to do this with the image you provided, it would go roughly like this:

1. Mask out the image in Photoshop/Gimp to divide it into layers, with each containing an image corresponding to a flat surface in the 3D consideration.
2. Extend some of the layers that show behind others so that as the camera later pans, there will be enough of the layer to show correctly for the panned view. (Think about the wall layer behind the chair.)
3. Import the layers into Spine and attach them all to a skeleton.
4. Adjust the attachment offsets until you recreate the original image.
5. Create a new animation for panning left.
6. Add a mesh deformation to one of the larger attachments, like the right wall.
7. Create a key that deforms the attachment to be what it should be at end of your left pan.
8. Add more keys in the middle frames as needed until the attachment looks correct across the whole pan.
9. Repeat steps 6 through 8 for the remaining attachments, until eventually every attachment pans left.

Easy!

No, not easy at all. If you complete this, it will be a triumph for the ages.

Beautiful. Many nice details in the movements.

@klaude, I will have to try the same (or at least similar) thing soon. I was hoping that if the animation contained no keyframes that set the attachment on the same slot, I'd be able to combine calls to setAttachment() with a playing animation.

Hmm. I'm inspired to stop watching Youtube videos and go code it up.

Experiment results: It works fine, at least for what I am doing. The animation plays without conflicts. I am also using calls to AnimationState.setAnimation() and Slot.setAttachment().

I figured it out.

The problem attachment depicts eye lids. I want them to blink in a downward motion. That is what my code snippet above does in its full, non-simplified version.

For the skeleton that wasn't working, there was a neck bone with a rotation value of 90 degrees. The Y value I was adjusting was moving along the screen X axis because of this 90 degree rotation. It makes sense for it to work this way. I just got confused because visually, in the editor, the attachments at a quick glance didn't look turned at 90 degrees. I remade my skeleton in the Editor to remove the 90 degree rotation, and after that, the blink code was again moving the lids vertically instead of horizontally.

I missed your message before I posted mine. Still, your explanation is useful. Thanks!

I was speaking not of the .x value itself changing.

The rendered horizontal position of the attachment changes. So just looking at the screen, there is an eye lid (the attachment) on a face that is positioned to the left of the face.

If I comment out the call to updateOffset() the attachment will be rendered horizontally correct when I see it on the screen. So something about this call makes the horizontal misalignment occur.

I have some code like this:

attachment.y = 50;
attachment.updateOffset(attachment);

When the call to updateOffset() is made, the y position will update as expected, but the x position also changes for the attachment with end result of misaligning the attachment leftward of where it should be. If I don’t call updateOffset() the attachment is aligned as expected on x.

The code has this problem for just one of my skeletons, with all other skeletons working fine. Two differences for the problem skeleton are 1. the attachment is parented to a bone instead of directly to root. 2. Skeleton Jsons are exported from the latest 3.7 beta as of last night whereas all the other skews are exported from an older 3.7 version. (Can look up exact versions when I get home.)

I am using the latest webgl runtime from the 3.7 branch on github.

Will dig into this deeper and try to narrow it down, but maybe there is something easy to fix that I’m doing wrong.

You may want to combine your skeletons into one skeleton, and use animations to set visibility of one pose at a time. So say you have a "front view" animation. This animation could set keys at the beginning of the animation to hide all the parts for the other poses and just show the "front view" parts.