• Editor

  • Question about Mesh Attachment and Request

Hello guys,

First of all, great job with the free form deformation feature! I've seen kickstarter video and It looks amazingly promising. I have a question about these mesh atatchment though... Is it possible to have "mesh-skin" attachment in order to have different skins that use free form deformation? and also, what hapens to the vertex we add to these mesh attachments when we would change skins? is all the animation data lost in the process of changing images?

Also I would like to feature something a request that may be interesting to do. I think it would be a nice adittion to have a way to tell spine to frame-skip our animation without having to step our curves on every keyframe or without having to alter our already soft interpolated animation in any way. The purpose of this would be to make soft interpolated animations look like raster animation. It is currently possible to achieve this effect by altering the time variable on runtime, but It would be nice to be able to see it on the editor and check out different time values there too. Also It may seem like a dumb idea since the animation would look rastered, check out any vanillaware game on where most of animations are done like this, or the upcoming guilty gear game (trailer here http://www.youtube.com/watch?v=NKGPhKu3jNg) which although being in 3D, the animations are all rastered.

Related Discussions
...

An attachment has a setup pose deformation, separate from a deformation an animation might do. Eg, you have a helmet image, you can have an attachment use that deformed one way and another attachment (in the same or different skin or slot) that uses the same image but is deformed differently.

The plan is to store deformation information relatively in animations. Eg, an animation moves a vertex +50,-25. If you change the image, the vertex still moves. Maybe we can also store the size of the image used to move the vertex, so if you change to an image that is a different size, it moves that vertex an amount adjusted by the ratio of original and new image size.

For your second wall of text 😉 I think you are asking for playback that doesn't interpolate between frames. I can add that to the playback dialog.

So from what I've understood, if you are using different images for a single skin attachment (switching skins or switching images during an animation) you have to use the same number of vertex as the vertex information is related to the slot rather than the attachment right? that way you would keep vertex movements even if you change images, seems like a nice workflow.

Yes that's exactly what I mean by that wall of text, similar to when you export a gif with a FPS setting lower than 60fps (which is what I do to previsualize that kind of effects).

By the way, can you still choose to make "non deformable" slots in order to save some resources in some animations?

Thanks a lot for your answers Nate, I'm already all hyped up for those new Spine features, you two are really making the perfect 2D skeletal animation software!

Animating images inherently limits you to the specific images you are animating. If the replacement image has the same mesh, it can work if we store the vertex changes relatively. If the mesh is different we can still apply the animation, but the new image is unlikely to deform how you want. Maybe this is just something the user needs to watch out for. I suppose this can lead to an animation per image, if your images are not similar and you need to deform them.

I'm open to ideas on how to make it more flexible.

Maybe an animation can have a timeline for each image instead of each slot. Eg, you have a single animation and images A and B which are each in a different skin. You would animate with A visible and deform it. When you switch skins so B is visible, B does not deform at all. You could then add keys to the same animation to deform B. At runtime, if A is visible it uses A's deform keys and ignores B's deform keys, and vice versa.

If you change an image during an animation, you should be able to manipulate the new image's vertices just fine. Eg, image A has 6 vertices, image B has 9. You key vertex changes for A, then switch to B, then key vertices for B. This could work if we store deform keys in a timeline per slot or per image.

Yes, you can use a "region" attachment which is what we have now, or a "mesh" attachment which is new. The mesh can have 3 or more vertices, so you only pay the CPU cost for the vertices you need.

I'm 100% for the idea you've written above; it'd be perfect for each region/image to have its own deformation animations. 🙂