Ah, I see; sorry about that. I should have taken a closer look at the libgdx runtime changes.

In version 3.3.03, weighted meshes are exported with the type 'mesh' instead of 'weightedmesh'.

I agree with Shiu. It seems more useful the way it is.

The shear described in the link is closer to the skewX and skewY used in CSS transforms.

| cos(cssRotate) -sin(cssRotate) | * | cssScaleX     0     | * |       1       tan(cssSkewX) |
| sin(cssRotate)  cos(cssRotate) |   |     0     cssScaleY |   | tan(cssSkewY)       1       |

In Spine, ShearX and ShearY modifies the X and Y axis rotations independently, which modifies both a scale and a shear in the transform matrix.

| cos(spineRotate) -sin(spineRotate) | * | cos(spineShearX) -sin(spineShearY) | * | spineScaleX      0      |
| sin(spineRotate)  cos(spineRotate) |   | sin(spineShearX)  cos(spineShearY) |   |      0      spineScaleY |

I was expecting the ShearX and ShearY modifiers to control only the shear components of a transform matrix, so I needed to update my runtime when the feature was implemented in Spine 3.2.

http://jsbin.com/vifuyuvezu/edit?js,output

I agree that the independent axis rotation is a more useful effect.

Change Shear X (or Y) on a bone in Setup and export. Bone object in JSON does not include shearX (or shearY).

Create a transform constraint with modified rotation. Rotation exported as "x" in JSON; should be "rotation" (like bones) or "rotate" (following "rotateMix" notation).

I've checked in a few fixes to the Spine C2 plugin. While it's still a work-in-progress, if there are any specific issue fixes or feature additions you would like to see, please add them to the issues in the github project.

I've made a version of the GIMP script to support some of the features of my Photoshop script.

https://gist.github.com/flyover/e6e1f125e5aef585815f

It uses a GroupLayer for organizing bones, slots, skins and attachments of a Spine project. The exporter uses the Layer name to connect attachments to slots and slots to bones. It also uses the center of the bone layers for the bone location. There is also basic support for importing a JSON file back in to GIMP (regions without any rotation).

Here is the Photoshop project:

https://github.com/flyover/psd2scml

In the GIMP Preferences dialog, there is a section under Folders for Plug-Ins. This is a list of folders where GIMP will look for plug-in scripts. You can either copy the script to one of the listed folders or add the folder of the script to the list. Restart GIMP and the Export to Spine menu item should be in the File menu.

Yes, it looks like it works in Chrome, Firefox and Edge on Windows 10.

Would you mind if I added the example to the demo?

I've recently updated my Spine JavaScript runtime to support some of the new features in Spine; including IK constraints and free-form deformation.

https://github.com/flyover/spine.js

There is also an demo with both WebGL and Canvas renderers. The WebGL renderer does the bone blending and free-form deformation mixing on the GPU. The Canvas renderer supports regions, meshes and skinned mesh attachments, including FFD. I'm still looking for a solution for slot color in the Canvas renderer.

I've tested with most of the examples I could find online. I'm looking for more examples to test and feedback on what needs to be fixed. Thanks!

I have a Photoshop script that you might find useful. It was written to export a Spriter SCML file and support for Spine was added. For Spine, it exports a *-skeleton.json file which must be imported to an empty project. If there was a plain-text version of a Spine project file, I would add that as well.

The script uses a group hierarchy with layers defining the locations of bones. There is an example PSD included with the project. One with a full hierarchy and one with all objects bound to the root bone.

https://github.com/flyover/psd2scml

Yeah, that makes sense. For this to work, the higher res images would need larger gaps between the regions. Not exactly ideal. Thanks for hearing me out.

If I had the dimensions of the image used to compute the regions, I could swap out the atlas image (example.png - 1024x1024) with a low-res version (example-low.png - 256x256) at runtime and use the same atlas (example.atlas) by scaling the "xy" and "size" fields by 256/1024 (normalized texture coordinates) without needing to load example.png to see what the dimensions were.

var atlas_png = atlas.page.name;
if (low_res)
{
    atlas_png = basename(atlas_png) + "-low.png"
}

Nate, would you consider always adding the original dimensions of the page used to compute the "xy" and "size" of each region in the atlas? With this, normalized texture coordinates could be computed and the texture dimensions wouldn't matter.

tex_matrix.identity();
tex_matrix.scale(1.0 / page.w, 1.0 / page.h); // region in page pixel units
tex_matrix.translate(region.x, region.y); // from atlas.region.xy
tex_matrix.scale(region.w, region.h); // from atlas.region.size