यह साइट एक आधुनिक ब्राउज़र में सबसे अच्छी तरह से देखी जा सकती है जिसमें जावास्क्रिप्ट सक्षम है।

Spine Editor what's next after 3.7!!!

foriero

Added rulers into original post. :-)

foriero

Ok lets go over it more in depth. We have one character in one spine project and we have second character in another project and then we have animated environment(s) in other spine projects. Now what we need to use character1 and character2 in those different spine projects environments. Right now I can export and import both characters but that way I loose all connection with our original characters and whatever animation we create in that environment spine project with those characters won't be reflected to the original characters spine projects. So the only solution to keep that all or parts of what we animate in that environment spine project on those characters we call "Linked Skeleton..."

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.

There is though one caveat. In producing Peppa Pig like youtube series we need only base animations to be used and then there are like environment specific animations for that particular episode. Like moving whole body from left to right on the screen since there is something happening in the scene.

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. So like two different animation saving. One in that file where they are linked and one reflected/saved to the original character file.

That way we will be able to work on characters and their base animations in time and develop them and on the same hand we wont fill animations in that base character spine project with so to say episode/environment specific animations like that moving around in the environment which is in no way related to base character spine project.

Let me know if this is more clear now. Or is there any other model you have in mind that can solve this episode production needs?

Nate

foriero लिखा
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 लिखा
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

As I understand linking other project into current project is easier and more straightforward than liking skeleton from other project into current project.

We can live with that and all ok. :-)

Also regarding the animations if they are somehow grouped then all is manageable and nice.

To have only one file with all skeletons is not desirable since we need to share projects with different animators and to share huge projects that contain tens of skeletons is not teamwise manageable.

So to recapitulate. Having Linked project is great. :-) Thank you for that. And having grouped animations is also nice. :-)

I would humbly ask you guys to implement those two features in next version. :-)

Have a nice day, Marek.

Updated initial post for :

Link project...

Allows to link project into current project. The concept of linked project(s) allows us evolve characters in their respective spine projects but use them in production of animated movie/youtube episodes as needed. Also it will allow us to send more projects to different animators at once and once they are all done we can then link all those projects into one and composite final episode scene animations.

Animations grouping

Since linked skeletons workflow for Peppa Pig like episodes will result in many animations that are just situation and environment specific we need to group the animations into logical groups. For example Episode01, Episode02.... groups.

Updated inital post for :

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.

fantasyz

foriero लिखा
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.

foriero

Check for Launcher Update
"Check for launcher update!" on onset just before you check for new spine version. And if possible download that new launcher and install it automatically. It takes pretty lot time with the cadence you post updates to install the spine launcher over and over again. May be it is not possible but for sure you see how to improve it.

gruen

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

foriero

Nate, is that bend mask possible or is there a reason why the mask is only allowed to use straight line? M.

Erika

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.

wilds

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

Erika

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?

scardario

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.

foriero

Images Scale Factor
Imagine that you have exported AI file into Spine and already did all animations. That export resolution was for example targeted to 2k displays. Time goes by and there is need to make the whole already made animations for 4k devices. So if you regenerate AI file into Spine with 2x then spine simply won't correctly display the work done in past. And for that we need simple float value for each spine project ( may be skeleton ) which will determine exactly this scale ratio of images to original images that the Spine was first time animated with. ( It is a bit similar concept like pixelsPerUnit in Unity )

Nate

scardario लिखा
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.

scardario

Nate लिखा
this is now possible in the latest 3.7 beta!

😃 Thank you! That was a much needed feature

foriero

Project "lock" file
Most of the teams today work over dropbox or other clouds. It happens often that two animators open the same project at the same time and do changes. Dropbox thankfully take care of this and we get conflicting files so that we can merge them. But still it is hassle. Simple solution would be to create "lock" file next the the spine project so whoever is trying to open that project that is already opened on other machine will be able only export it or view it.

Thank you Nate for the rescaling tip. I have implemented into our IntegratorTool2D and works wonders. :-)

AxiomVerge

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.

jollibee

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

AxiomVerge

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.

Nate

@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

« पिछला पन्ना