• Editor
  • A better way to assign things to skins.

  • Düzenlendi
Related Discussions
...

Hello, I doubt I am the only one think that the current skin assignment workflow can be improved. However, there seems don't have much discussion about it so I will do the 1st step and bring out the better approach in my mind here.

Basically, the idea is to minimize user input (mouse / keyboard works) and maximize presentation (simplicity, consistency and clearness).

The Problem

The way to assign stuff to skin is inconsistent right now. For bone it has a "Add to skin" button and for attachment it has a series of action to take: add skin placeholder, select the target skin, drag attachment to SP. If want to assign to multiple skin, we also need to clone attachment and select another skin and drag again. If you have a part shared by 7 our of 10 skin, you need to do this 7 times. About the skin placeholder, I think it is a programming stuff and just representing a structure in the data. I have been using spine for quite some time now and have a feeling that Skin Placeholder is not something to be shown to the user but should be something hidden in the code. All user want to see and do is an attachment under a slot and the ability to map attachments to skins that is it. That extra SP node only add complexity from user's perspective.

The Suggestion
First of all, a panel is added in to make things consistent and clear.
When a supported object is selected, the panel show which skin is mapped. Assigning to or removing from a skin is just one click away. Most importantly it is consistent for whatever selected. No more skin placeholder.

Next thing I would suggest is to allow more types of node to be able to assigned to skin in addition to bone and attachments. Somethings assigned may not have an impact on the export/output but could improve presentation by simply filtering them out. The goal is to make multi-skin project as clean as single skin project. When a slot, constraint, animations is assigned to a skin, simply don't show them in the hierarchy tree and draw list etc. This help make the project more manageable.

How does it sound? ~ 8)

Hello Nick,

We added the skins view to provide more control over skins already: Skins view - Spine User Guide
It allows to show multiple skins at the same time by pinning them and reordering them, export them combined in videos or gifs, and so on.

Skin placeholders exist because not all skins may have an attachment/mesh/path/point/clipping/etc. inside, and this allows to animate their visibility using, as the name suggests, a placeholder. Therefore we cannot remove them.
Also you can add anything that goes in a slot to a skin, and now bones and constraints too, so anything except events can go in skins.

You can use folders to organize your animations by skins to reduce the clutter.

You can also hide bones and constraints from inactive skins in the tree, this is dusabled by default to avoid confusion in new users, but you can activate at any time here:

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

Hello Erika,

Alright, now I understand why there is a skin placeholder (for keying visibility). Oh god, I want to get rid of that SP node. Its very wasting space and is killing my eyes. I just wonder, why is the visibility not controlled by the slot? I mean if the color of the things below are controlled by slot, why is visibility different. They both are visual properties, right? Not to mention when slot is hidden, the spine program will give me warning during export. It is like the slots visibility dot is useless (or a trap) unless for temporarily turning off the visual.

(Update: I understand the visibility dot on attachment is manly for frame-based animation and it make sense this way. It just that I don't understand why an turned off visibility on a slot would give me a warning. )

About the skin filtering, I already turned on all filtering to reduce clutter but slots still cannot be assigned to skins for filtering purpose. This is the most wanted because slots affect how much items are showing in the tree And the draw order list. Imagine thing like this (http://esotericsoftware.com/forum/Folder-to-draw-order-13396?p=59259&hilit=+draw+order#p59259) could be prevented if slot can be filtered too:

Folder could help the situation but when the amount of skins increase, the folders itself could already be occupying like 10+ rows. Thanks for reminding me that beside slots, animations and folder should be able to add to skin too.

Anyway, the suggestion of this topic is about the step or workflow for "Adding stuff to a skin". Imagine using a panel (a standalone one or build on top of existing Skins view) and just one click to assign to a skin is a big improvement over the traditional way. Not to mention it also provide a quick way to see which skins owned the attachments.

Suggested workflow:

  1. select an attachment
  2. check the checkbox next to the skin entry. (SP auto added when needed)
    (Same workflow for everything else, great consistency)

Current workflow:

  1. Select slot
  2. Add SP
  3. Select skin if not already activated
  4. Drag attachment to SP
    (if need to apply for multiple skins, need more cloning, renaming, skin selecting and dragging... :sucks: )

There are 4 ways to add things to a skin. Besides inconsistency, all of them require more or less dragging and clicking around, which is not as straightforward and informative as the mentioned design.

1.Drag the object to the skin (cannot drop to skins view)
2.Use "Add To Skin" button from a skin
3.Use "Add To Skin" button from a bone
4.Use "Skin Placeholder"

Bone only support: 1, 2, 3
Constraint only support: 1, 2
Attachment only support: 4

Its a good design, think about it.

Nick yazdı

It is like the slots visibility dot is useless (or a trap) unless for temporarily turning off the visual.

(Update: I understand the visibility dot on attachment is manly for frame-based animation and it make sense this way. It just that I don't understand why an turned off visibility on a slot would give me a warning. )

It is true it's a bit of a UI trap


it is confusing for new users. Hiding the slot is only really useful for temporary turning off visuals, as you said. The warning is given because people hide slots, then don't understand why the attachments for the hidden slots are shown at runtime but not in the editor.

I'm not convinced adding slots to skins is the right thing to do. However, we could hide slots in the draw order for bones that are in a skin that is not active. This is a little tricky to implement, as the draw order needs to consider that there are items not shown.

I'm also not sure about adding animations to skins. Animations maybe, as it would make sense for some skin-specific animations, but then they could just be placed in a folder.

Instead of adding folders to skins, if we hide things in skins that are not active, we could hide folders that are empty because of that.

Imagine using a panel and just one click to assign to a skin is a big improvement over the traditional way.

If you mean bones and constraints, you can already do this. Click a skin, click Add to Skin, now go and click a bunch of bones and constraints


each click adds one to the skin.

Or do you mean to add attachments to skin placeholders? Note that is a different action than for bones and constraints. It can't be one click because it doesn't just "add to the skin", it sets the attachment for a skin placeholder for the current skin. Spine needs to know 1) what attachment to add to the skin, and 2) what skin placeholder to add it to.

You can move many attachments to new skin placeholders in one action: select any number of attachments not in a skin, click New... > Skin Placeholder. If you already have skin placeholders, eg this is your second skin, then maybe Import Data can be used to place the attachments into the skin placeholders without any extra work.

Thanks for taking time to discuss the details.

I'm not convinced adding slots to skins is the right thing to do. However, we could hide slots in the draw order for bones that are in a skin that is not active. This is a little tricky to implement, as the draw order needs to consider that there are items not shown.

The ideal case is to have everything as simple as a single skin project when a skin is selected. Hiding unrelated slots is the best case scenario from a animator perspective but even if just getting them hidden in draw order could be a big help too 🙂 .

Another less optimal but more safe approach is to mark those active or unrelated slots/item out. Emphasize them visually so that user know it when they see them. e.g. use another color say blue for skin active items (or just let us customize colors for active and inactive rows), while keeping the rest white would help make things standout. (note: cannot use semi transparent to mark inactive items because this will confuse with search filtering.) The more easy our eyes can identify them out the better. I think this could be the default behavior and then we could further turn on "hide skin slots" just like the "hide skin bones and constraints" to have things as simple as possible. I could imagine it would be so great when they work together.

Instead of adding folders to skins, if we hide things in skins that are not active, we could hide folders that are empty because of that.

That will do. 🙂

If you mean bones and constraints, you can already do this. Click a skin, click Add to Skin, now go and click a bunch of bones and constraints


each click adds one to the skin.

For a selected skin scenario, you are absolutely right. This is one click to add multiple items to a skin and is excellent. However, when user want to add one item to multiple skins, that is another story. This scenario is actually more frequent because we generally already have bunch of items auto added to a skin during the import phase but we do from time to time add new items, by fixes/updates, to multiple skins.

Or do you mean to add attachments to skin placeholders? Note that is a different action than for bones and constraints. It can't be one click because it doesn't just "add to the skin", it sets the attachment for a skin placeholder for the current skin. Spine needs to know 1) what attachment to add to the skin, and 2) what skin placeholder to add it to.

If I am correct, there is only two cases for adding attachment to a skin.

  1. add to an existing Skin Placeholder. (just drag or 'set parent' as we currently do, I don't think this can be improved)

  2. add to a new Skin Placeholder / add to a skin locally under a slot.
    The desired control is to have skin represented button / checkbox (or even just ctrl+click on the Skins View's skin item if you don't mind people could miss this functionality) to allow one-click and auto add SP in-between the slot and attachment. No need to select skin and new an SP and confirm SP name, drag item to SP. If need to add a default skin attachment to 4 skins, Just 4 clicks and is done. Nice~

6 gün sonra

I completely agree with Nick's considerations.

I thought I could create my attachment-dependant animations with the new skin system, I can't.
As you guys took one step toward "skin specific animation" with the bone-skin relation I can't see any reason why we couldn't use the same principle with attachment and/or animations based on skin.

Right now I find it really hard to toggle on and off a weapon visibility at runtime. Actually I don't even know how without checking which weapon should be displayed on every start of every animation and manually set it. Maybe I missed something ?

Also : slot visibilty is a bit*** :p :p