foriero wrote

Linked skeleton physically resides in different spine project. All animations and rig is linked so whatever change we do is reflected to that original spine project.

This is a pretty OK suggestion, though it is complex to implement as we have to go from there always being one project to there being many. Making that change is high risk as many, many places in the code need to be adjusted and it is error prone because missing an adjustment likely appears to work, but references the wrong project and will break later.

So what we need from Linked Skeleton is to have project in which they are linked ( environments ) to have possibility to store those episode specific animation inside that project and base animations that are saved into character own spine project.

This adds a ton of unnecessary complexity. A skeleton should contain all its animations, not have them split across projects. Many actions modify all animations, eg deleting a bone has to adjust all deform keys in all animations. Possibly a better solution is to allow "folders" to organize animations, then you can at least group scene-specific animations.

The current workaround is to use a single Spine project. All your skeletons are in one place. Use a skeleton per scene and hide it when working on other scenes. Your problem stems from wanting to separate skeletons into separate project files. I know there are reasons to do that, but an enormous amount of effort is needed to better support linking project files ("linked project" makes more sense as a feature name, IMO).

ilusha wrote

We definitely need a skeleton attachment ("link skeleton" from the topic).

Note the "linked skeleton" proposal above is not the same as skeleton attachments.

foriero wrote

Mix Times View

For easing developers setting correct mix times in their respective engine it would be actually nice if Spine Editor can have Mix Times View where animators can prepare transition mix times so that all looks nice after export. If not defined the default 0.2 is used.

Agree. To be precise, what I would like to see is an improved Preview view that can define a sequence of animation and a place where I can add a custom mixing entry with a mixing value and to/from animations.

Here is an example for that view:

Mixing duration to 'Dash'                             [+] // Add New Rule Button
[Idle]   0.1   [  ] Wait loop end.
[Jump]   0.0   [x] Wait loop end.  // no mixing and wait until Jump animation complete its timeline/loop.
*        0.2   [  ] Wait loop end.  // local default mix value for THIS Dash animation from everything else

The panel better show only the data related to current selected animation to make things easier to read.

Note that some animations may require only a single custom mixing value to every other animation. Its better to support a animation local default mix value. e.g. Hurt animation usually need to play fast with small mixing value. We don't want to change default 0.2 just for Hurt. Changing the local default is more appropriate.

Mask
i would like to bend the path of an mask instead of only being able to place straight lines

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.

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 wrote

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 wrote

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

Another thing just came up...if there was a way to add properties onto bounding boxes (or maybe just anything in hierarchy in general), so that you could have Hit, Hurt, Collision, Weak Point, etc. as options. The workaround I am using is to make these properties a part of the name and then parse the string.

@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