I've already answered the Launcher update here: Check for Launcher update!

Regarding the mask feature, the user guide should be clear about it: Clipping - Spine User Guide

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.

Most engines wouldn't be able to support it at all, unfortunately. I agree it would be very nice, but considering also how expensive it is at runtime, maybe finding an alternative solution would be better.

@gruen if you want, you can write an example of what you would like to achieve and I can help to find an alternate way of doing it.

Would love to see a possibility of adding a z coordinate to allow for 3D skeleton manipulation.
Yeah I know it's spine2D.

In a sense, you could consider the z the draw order, you can also get parts of the same mesh to bend in realistic 2.5D ways really. (the upper the bone in the weights panel bone list, the most forward will be the vertices influenced by it).
What exactly did you picture @wilds that differed from these two already present features?

I'd love to see the possibility of having separate keyframes for each point (a bezier point + its 2 handles) on a path deformation, maybe having the option to have a single key for all vertices (like it's working now) or separate, or maybe another kind of path with separate keyframes for its deformation.

Right now the workaround to handle a curve with separate keyframes is to assign a bone to each point you want to control, but if you also want to control its handles, you'd need a lot of bones and the rig can become too complex, besides, you don't have control over the way the handles change the curve (by pressing Alt you can set an acute angle, but you have to keep it pressed to make it work, unlike other software, the mode will reset to the default if you unpressed Alt).

The way I handle this is by using both features: bones to control some points and deformation keys to control the handles when needed, but I think this approach increase the complexity of the rig.

Ahh, and I'd like the Offset tool to work with deform keys, I find paths extremely helpful to animate secondary actions but I can't use one of the best tools Spine has to offer to that purpose.

scardario yazdı

Ahh, and I'd like the Offset tool to work with deform keys, I find paths extremely helpful to animate secondary actions but I can't use one of the best tools Spine has to offer to that purpose.

@scardario, this is now possible in the latest 3.7 beta!

@foriero you can export to JSON, then use Import Data to bring the data into Spine scaled:
Import - Spine User Guide: Scale

That is what you would use if you want to change the size of the images used in Spine. However, there is no need to do that at all! You can continue using the same art (for 2k displays, in your example) then simply pack an atlas that is 2x of the size of what you use in Spine. At runtime specify a scale of 2 when loading the data. You can read more about it here:
Loading Skeleton Data - Spine Runtimes Guide: Scaling

In fact, this allows you to have any number of atlases for different screen sizes. You could choose which atlas you load at runtime, based on the native display resolution.

Nate yazdı

this is now possible in the latest 3.7 beta!

Thank you! That was a much needed feature

Late to the party, but for me, the Curve Editor is the most important thing. Just copy Maya's curve editor.

Next up for me would be some automation for image sequences; like you export a sequence (or maybe even a GIF) from whatever sprite tool and the UI could treat it as a single unit where you can key "Begin Playing", "Stop Playing", "FrameRate", etc.

Is it possible add something like this: https://www.reallusion.com/crazytalk-animator/facial-mocap-live-face.html

@AxiomVerge, it's probably best not to encode game data in Spine. It may be convenient but, eg needing to edit your skeleton/animations to change the damage an enemy does probably isn't ideal. Still, we have an issue for arbitrary properties:
https://waffle.io/EsotericSoftware/spine/cards/574b9787c858761e00f3e520

Nate yazdı

@[silindi], it's probably best not to encode game data in Spine. It may be convenient but, eg needing to edit your skeleton/animations to change the damage an enemy does probably isn't ideal. Still, we have an issue for arbitrary properties:
https://waffle.io/EsotericSoftware/spine/cards/574b9787c858761e00f3e520

I think AxiomVerge maybe suggestion something like tag. Not key/value pair.
Well, if tag is available, it can be used to apply filter too.
e.g. when all parts of head is tagged "head", can do quick filtering to filter out non head parts from the skeleton tree.
Can be done easily by entering the tag name to current search box and auto turn on filter mode with search target switch to tags instead of item names.
But the hierarchy could became very messy when items have too many tags on it unless tag can be optionally hidden from the name.

It is a nice to have feature but I am not sure how much priority will this feature get as there are something more demanded in the TODO list. Most importantly, AxiomVerge is doing fine with parsing the name. :rofl:

fantasyz yazdı

I think AxiomVerge maybe suggestion something like tag. Not key/value pair.
Well, if tag is available, it can be used to apply filter too.
e.g. when all parts of head is tagged "head", can do quick filtering to filter out non head parts from the skeleton tree.
Can be done easily by entering the tag name to current search box and auto turn on filter mode with search target switch to tags instead of item names.
But the hierarchy could became very messy when items have too many tags on it unless tag can be optionally hidden from the name.

It is a nice to have feature but I am not sure how much priority will this feature get as there are something more demanded in the TODO list. Most importantly, AxiomVerge is doing fine with parsing the name. :rofl:

It's definitely not the highest priority... many games I've worked on relied on naming bones things like "FootballBone" or "Muzzle0...N" and then the code parses it. I was thinking also maybe I can distinguish Hitboxes from Hurtboxes by changing the color...once I figure out how to read it back out at runtime

Sorry, bounding box color doesn't make it into the skeleton data. It could be that it's only exported when Nonessential data is checked, since it isn't normally needed, but currently it isn't exported at all. We have a short list of nonessential data we'd like to add (bone icon, bone visibility, slot visibility, etc). I've added it to the list!