• Editor
  • Skin Creation Workflow Questions

Hey there,

Currently exploring the use of Spine as our 2D skeletal animation solution in combination with 2DToolkit/Unity. Really enjoying using the tools overall! However, questions abound, as the documentation is somewhat thin.

We're looking at creating skins for a subtype of a character type, so we can have a great deal of variety in our characters at very low cost.

Our game features insects, so let's say we want to author one set of animations to be applied to N different sub-types of hornet.

We author the art for multiple hornet types in photoshop layers, export the layers (trimmed), and have them ready to pull into Spine.

The skeleton has been rigged for the 'standard' type of Hornet. Time to create a new skin for the 'alternate' type of Hornet.

I create two skins: "standard" and "alternate"

Now, for each socket in the already-rigged skeleton, I have to go add a "New Skin Attachment". With the 'standard' skin selected, I drag each of the previously socketed images into the skin attachment.

I switch over to the "alternate" skin and all those pieces from the "standard" skin are missing. Well, that's kind of annoying, because I have no frame of reference for positioning pieces of the skeleton (except for the bones, which aren't all that useful since I want everything to line up exactly).

Now I have to place every image from the "alternate" skin individually and manually re-align every piece of the skeleton, since bringing them into the hierarchy instantiates them at 0,0 for some reason.

Perhaps I'm approaching the workflow incorrectly and could use some pointers on how better to approach this, but it seems there are a few things that might make this situation better:

  1. Shouldn't instantiating an image into a socket automatically set the translation/rotation/scale of the image to match the settings of the existing image in that socket? Instead it's putting everything at 0,0 but with a seemingly random rotation.
  2. It'd be super nice if you could copy/paste the transform of a node in the hierarchy, and would accelerate this process a lot. As is, I have to manually copy values from one skin to the other, which is basically just impossibly slow (and error-prone) busywork.
  3. Isn't a very common use case for skins total replacement of every image in the skeleton? What if there was a way to auto-skin

say you had your images in 5 sub-directories with the same filenames? Then add a "create skin from directory" button, allow me to choose my directory, name my skin, and voila, auto-generate all the necessary skin attachments, move the new image references to the corresponding attachments at the same transform locations.. DONE. (I realize as I say this that I can't have all my source images named exactly the same thing due to conflicts in the texture atlas, but the point is that this entire process should be automatable, and instead is a lot of manual drudge-work)

Thanks again for a fun and useful tool, I hope we end up being able to use it for our next game!
David

Related Discussions
...

I agree that we can definitely improve the skin workflow. BTW, "socket" is a pretty nice word, much better than "skin attachment", which leads to silly buttons like "New Skin Attachment".

  1. It could but which one would it use? There could be many. It could prompt, but what if you don't want this?

  2. Copy/paste for attachment transform would be good. It would still be tedious though, as you'd have to switch skins, copy, switch skins, paste. I'd like to implement being able to drag and drop an attachment on to an existing one and the new attachment would copy the transform of the existing one. For skin attachments, it would also replace the existing one in the skin. Then the workflow would be setup a skin, duplicate the skin, drag images on top of the existing ones and then adjust them.

  3. There shouldn't be conflicts in the texture atlas, as the relative path to the image should be included in the image name. Some way to do it automatically would be nice. We'll give it some thought.

Something else we've thought about is showing multiple skins at once. This can be useful when you plan to use skins to group attachments and will combine skins at runtime. This could possibly help with aligning images in additional skins. Not sure on the details of the feature yet (how the tree looks, how to order the multiple skins that are active at once, etc).

Note if you create your art with skins in mind, you can set everything up programmatically and not have to do it all in Spine. You need to design your images so they can all have the same attachment SRT, then you only have to rig a single set of images. The downside is that this will cause extra whitespace to have the image contents aligned to the setup pose.

I'd like to implement being able to drag and drop an attachment on to an existing one and the new attachment would copy the transform of the existing one. For skin attachments, it would also replace the existing one in the skin. Then the workflow would be setup a skin, duplicate the skin, drag images on top of the existing ones and then adjust them.

Yep, that seems like it would be a huge improvement over the current workflow. It's still manual and will take some time, but we're talking a couple of minutes instead of.. I dunno, I think it took me 45 minutes yesterday to make a second skin (17 bones?)

There shouldn't be conflicts in the texture atlas, as the relative path to the image should be included in the image name. Some way to do it automatically would be nice. We'll give it some thought.

Don't think 2dtoolkit sprite sheets work that way


you create them in Unity, so you're just dragging texture resources into their sprite sheet tool and it doesn't know about paths.

I was thinking more like you could establish a naming convention (say: numbered prefixes) that would indicate the slot an image belonged to. So you name bones like this:

01_Hornet_Spine.png
02_Hornet_Stinger.png
03_Hornet_FrontLeg1.png
(etc)

01_BlackHornet_Spine.png
02_BlackHornet_Stinger.png
03_BlackHornet_FrontLeg1.png
(and so on, to match the first set)

Bones pull their ID from the number in the first N characters of the filename.

Make a new skin in the editor, click the "Import Skin from Directory" button, point at the sub-directory with the black hornet art in it, and then make it so.

I realize the filename convention is clunky, but the ideal workflow here (for us anyway) is to just generate source art and "press a button" to pull it in.

Again, I'm not totally sure how other folks intend to use skins. For us, really the main thrust is to get variety of artwork (different character types) with low texture atlas overhead. We're not looking to have radically different skin pieces per character type, it will probably often be straight replacement of parts. Would be very happy with your first suggestion 🙂

Cheers,
David

bir ay sonra
bir ay sonra

Note attachments can now be drag and dropped on another to copy the SRT. Also there is a new feature to make skinning much faster:
viewtopic.php?p=7762#p7762