3.6 took too long to release, though it was packed full of good stuff.

For 3.7 we said we'll do a smaller release. We had audio in shortly after the 3.6 release and everything was going well, then we packed it full of stuff and it has also taken too long to release.

The main focus of 3.8 is on adding a curve editor. The plan is not to get distracted with many smaller features so it can be released in a timely fashion!

Me likey! Curve editor will be amazing!

When implementing Curve editor in 3.8, should I expect x,y will also be controlled separately not only in the curve editor, but also on other part of the system like transform constraint? I think its a good time.

To me the most important thing right now is the Hierarchy panel, having Skeleton, Draw Order, Events, Image, Animation placed in a single Hierarchy panel is just a little annoying. They should have their own panel. I don't think I need to explain as there are threads discussing this before.
(the Spine settings popup also has this design issue, putting everything on a single page making a very long list. Luckily we don't need to change setting very often.)

Another feature I want is is to have most of those views to support "folder". e.g. Skeleton, Draw Order . Things starting to get out of control and is ugly to look at when a project has lots of parts. Being able to fold and freeze some part of the list would be a great help. It help make things easier to read and easier to drag. Although bone on skeleton can be used to fold things, it is just not easy to read as there are many bones. A bone is a bone but not a folder. It has side effects when trying to use it as folder.

Yet another feature I want is a UI for managing and visualizing stored Selections (those Ctrl + [0-9] ). Right now I just don't use this feature as I generally would forget I stored in those selection memory. It would be very useful if I can store the selection with a name and browse them in a panel. I could imagine I would be using it a lot to toggle visibility of parts. I found myself always need to change perspective of a part of the character and those part always include more parts. e.g. An arm perspective consist of arm parts, cloth, weapon, bracelet, etc. I would like to save perspectives to selection slots and switching between them with a panel.

As a user of spine for quite some time, I myself prefer productivity improvement a little more than new feature. (more productivity = save time, more feature like audio support could bring more work ) UI improvement directly affect how many time I need to spend to get the same amount work done and also affect the mood when using a software. It affect almost every user of spine. Some new features may take a lot of time to develop but only benefits small portion of user. I would suggest spine team should plan their time equally on both side. If one improvement can be done in a short period of time and save user working hours/efforts. It maybe better to let another time consuming new feature put on hold, or have them being developed in parallel if man power is enough.

fantasyz yazdı

should I expect x,y will also be controlled separately not only in the curve editor, but also on other part of the system like transform constraint?

Too early to say, but likely.

fantasyz yazdı

To me the most important thing right now is the Hierarchy panel, having Skeleton, Draw Order, Events, Image, Animation placed in a single Hierarchy panel is just a little annoying.

We have animations and skins. We'll do the others in time.

Hopefully things have improved slightly with regard to the tree scrolling since your previous feedback on this. To answer your question from there, Spine is designed to be tree-centric because in the beginning it did not have a view system

it had two fixed views, the tree and the dopesheet.

fantasyz yazdı

Yet another feature I want is a UI for managing and visualizing stored Selections (those Ctrl + [0-9] ).

Yep, we have plans for this too. I typically use the ctrl + number hotkeys as short term selection groups.

Regarding new features versus productivity and quality of life, I agree both need attention. We already spend a lot of time making things nicer and fixing bugs, though there is a lot we still want to do.

We definitely need a skeleton attachment ("link skeleton" from the topic). I have many different objects in my game and I need to mix them. E.g. place a squirrel or a bird on a tree between branches. And now I do not know other way only to copy an animal animation and paste it to a tree skeleton.

Also very useful feature is rulers.

foriero yazdı

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 yazdı

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 yazdı

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.

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?