Sure, I'd love to do that. I'll find some time for it one of the next couple of days.

Hi guys

Our company ACNE Production just released a mobile web app with Goodby, Silverstein & Partners - client is Tostitos.

It's a series of tools that let you boost your party if it's boring.

One of those tools is the Pocket Dancer, which let's you upload a photo of yourself and then have that photo perform a dance in the styles of hiphop, disco or Vegas showgirls.

We used Spine to create all the dance animations in the different styles with template images, and replace the actual skin with the one the user uploads. We created a custom rendering engine with Easeljs which uses the newest Spine.js runtime.

Check it out at http://www.bringthepartynow.com on your iPhone or Android smartphone. There is a desktop site there as well, but the Pocket Dancer tool is only available on mobile.

Martin Pagh Ludvigsen,
ACNE Production

You have the Boolean flag flipped in lines 1153 & 1154. They should be

boneData.inheritScale = boneMap["inheritScale"] || boneMap["inheritScale"] == "true";
boneData.inheritRotation = boneMap["inheritRotation"] || boneMap["inheritRotation"] == "true";

The way you have it now both properties resolve to true if they're false in the boneMap and vice versa.

Hey people

Our office is working on a project that will run in mobile browsers, and we've been playing around with a couple of the runtimes for rendering.

The official engine + Turbulenz works like a dream, but unfortunately it doesn't work on iOS because of the WebGL dependency.

So my first question is if anyone here knows how to make Turbulenz use 2D Canvas rendering instead of WebGL? Turbulenz' own site and documentation is all over the place, so I haven't been able to find anything there yet.

We've also been playing around with the Pixi.js runtime, which we managed to get working by using an alternative texture packer and by hacking it a little bit. Unfortunately there are some issues with it, the biggest one being that it doesn't support swapping the draw order. I guess the runtime was made back when Spine didn't support it.

So my second question is if someone has a version of the Pixi.js runtime with support for swapping draw order?

I've been playing around with a couple of the other JavaScript rendering engines, but I've kinda written them off, because they're already getting pretty old, so my guess is they probably don't support swapping the draw order. If anyone else has a suggestion for a good rendering engine, I'm all ears. Using Turbulenz for Android and something else for iOS would be perfectly acceptable, in case anyone has an iOS-only suggestion.

If all else fails, we'll either update the Pixi.js runtime ourselves or write a canvas rendering engine from scratch.

I actually know how to fix the problem now. Since we don't need to use inheritScale at all, I can simply default it to false instead of true.

So my problem is solved, but the repository still has the problem.

Thanks for pointing me in the right direction!

The updated spine.js didn't seem to fix the problem, and it introduced a new one where the textures aren't applied properly:

Take a look:
http://96.251.72.63/spine/turbulenz_new/

And this is with the previous spine.js:
http://96.251.72.63/spine/turbulenz_old/

On both animations, I'm scaling the chest and the upper legs. You'll notice that all the child bones of those bones scale with them. The reason the head looks right is that I'm applying the counter-scaling technique I described above.

FYI: The counter-scaling trick works, it's just a bad workflow and it makes the animations look broken in the editor.

Hi there

My company has bought a couple if licenses for your wonderful software, we're creating a series of animations, and everything has been going great so far.

Unfortunately we've run into a major issue after we started animating the scale of some of the bones in our our setup. Even though inherit scale is set to "off", any children of a given bone still scale with that parent bone when we scale it, and it really breaks our animations. I took a look at the json-data, and inheritScale is indeed set to "false" for every single bone in our skeleton. I've verified the issue with the Turbulenz rendering engine and the Pixi.js runtime, so it looks like the problem is in the JS-runtime. The animations looks just fine inside Spine and when we export them as MOVs.

Can it be something in our animation setup? Or is there a bug in the generic runtime?

I guess we could counter-scale the child bones with the same amount to prevent the issue from happening, but that workflow is extremely complicated, and I'd rather not have to do that.