• Editor

  • [Feature Request] Tags to filter assets

Related Discussions
...

Hello Spine team,

Here are 2 suggestions(i couldn't find someone mentioning these on the forum) :

1 - a Tagging system would be amazing. That way we could quickly Show/Hide whatever is on a specific layer or using a specific tag....

2 - Quick bone structure visibility toggle : If I turn off visibility of Parent bone, it will turn off visibility of all Children(Bones AND Slots)
This could be done by Shift or CTRL + click on the Parent visibility toggle.

Here's a scenario :

I have a character with a base body. I prepare multiple Gear Sets for this character.
Each Gear Set is made out of multiple bones, slots, images and are pretty complex.
Programmatically, we display the Gear Set selected by the player on the character.

Now in Spine, everytime I want to work on a specific Gear Set, I have to activate visibility on each one of the bones and slots that compose that given Gear Set to display it and work. Then turn them off again. This means up to 20-30 objects to turn on and off, sometimes more.

That would be extremely helpful when having loads of assets to deal with within a single skeleton.

Spine is amazing, but it still needs some extra features like these to really scale up to more complex type of productions.
Like, if file referencing was possible, rather than nesting all my Gears variants under the same skeleton, I would have created a separate Spine file per Gear and reference my skeleton and it's animations within that file, parenting my Gear to the referenced skeleton. (That's powerful and is something we can do with regular 3d animation packages)

thanks !
ben

One thing you can do is select all your stuff that makes up a "gear set" and press ctrl+1. Now when you press 1 it selects that. Clicking the visibility dot in the tree when multiple things are selected toggles them all. You can create "selection sets" this way with numbers 0-9.

Another thing that might help is to use skins to group your attachments. At runtime you can grab multiple skins and combine them into the one skin your skeleton uses. You might want to edit the runtime and avoid computations for bones that have no attachments if there are a lot of them.

We hadn't considered a tagging objects in your project, though this is similar to the "meta data" feature requests which would allow arbitrary name/value pairs on project objects. Tagging is interesting because of what it might allow in the editor, where metadata is more for at runtime. They are related though. Will give it more thought.

Hey Nate,

thanks for your intervention and thanks a bunch for the selection trick.

this is helpful now but we'll need much more than 9 selection set.
Do these selections get saved within the project file ?? we're 2 people working the same files, that'd be helpful to share these selections.

though it's a good idea, skins wouldn't work for us as our gear is a mix of bones and slots. I need to show / hide the bones as well, not only the slots. Skins do not allow me to do that.

We have about 30 bones on the current skeleton, we'll end with much much more. Probably around the 200 as we'll have 10th of multiple complex gear sets(gear pieces are all animated). + skin placeholder has to be nested under the same bones i want to show/hide.

Our project is rather complex, we build gear atlases at runtime, it's all modular.
But we have to author the gear in one single skeleton in Spine so that it animates properly and get properly updated if we change the animations of the character, which is as well, a rather complex humanoid. That's why I was mentioning that assets tagging and file referencing within the editor would be useful for such projects.

thanks !
ben

Selection groups are saved with the project.

200 bones is a lot. Should be fine on a desktop game, on mobile it could be a problem if you have more than just this huge skeleton going on. I guess if you are only actually computing transform for the bones in use it could be ok.

You can still use skins to organize your attachments in Spine, but you would still need an external config file that maps a skin name to the bones and slots that go along with it.

Another way to do what you are doing is to use a separate skeleton for each piece of gear. At runtime you can draw skeletons on top of your first skeleton at various bone positions. If you need more control over draw order, you could write an attachment that draws another skeleton. This way the other skeleton fully particpates in the draw order, like a region attachment would. Here is this implemented for spine-libgdx:

SkeletonAttachment, just holds a reference to a skeleton:
https://github.com/EsotericSoftware/spi ... t.java#L33

The rendering of a SkeletonAttachment:
https://github.com/EsotericSoftware/spi ... r.java#L86

It works and isn't much code, though this was done as a proof on concept. I also prototyped support for skeleton attachments in the editor (which actually uses the above), more on that here:
viewtopic.php?p=8569#p8569
You could still use separate skeletons and a SkeletonAttachment at runtime even if you can't preview them attached in the editor. You could use a region attachment solely as a placeholder for a skeleton in the editor.

Hi Nate,

Thank you very much for your help !

Yes it's a lot of bones and slots(that's why i'm looking for a way to organise that many assets in the editor). In our case, we have to parent the gear to the body skeleton bones as we need precise animation on the gear(like feathers and other objects) that have to be animated in sync with the body's motion.
Also, and more importantly, if we change the base skeleton animation(Run, Walk, Jump, etc...), we need the changes to reflect on all gear pieces animations.
So, separating the gear in different skeletons when authoring is not an option for us.
That's why file or skeleton referencing/instantiating would have been a huge plus for our project, but I guess that's a big feature.

What we do at runtime is "strip" the skeleton off of unnecessary bones and only render/compute transform on the ones we need(basically the base skeleton+only the gear that was selected by the player).

Our issue right now, on the art side, is mainly managing all these assets visibility when authoring animations with Spine.

Thanks !
ben