Skinning Editor : Sprite Categories and Labels Not Appearing

I'm working in the skeletal animation workflow and recently updated from 2020 to 2021 for a new project. There used to be columns in the Visibility panel in the Skinning editor for Sprite Categories and Labels, which were incredibly useful - however I'm not seeing those columns anymore.

Were these features replaced? Is there a new way to group sprites on a skeletal rig that we'll need to swap? Or am I just doing something dumb

Thanks!

 

I can understand that but why removing the Visibility panel for the bones? As far as I can imagine since I haven't tried in 2021, organising them and naming them in the Skinning Editor is a lot more practical than having to do it in the Inspector or by moving them around.

 

Ah, all right!

It's not normal that the op doesn't have this panel then. A bug?

 

So can I keep using 5.x if I upgrade to 2021?

How does this handle rigging? Will you need to recreate the entire skeleton for each sprite that isn't in the original file? How does this handle sprites that use bones that are now shown in the original object due to having no vertices bound to them?

This seems incredibly convoluted, especially if you have very large amounts of items to label.

What do you do if you have multiple swapping sprites in a single PSB file? Do you add SpriteLibraryComponents on each sub object that will be swapping or one on the root and relying on the groups and labels to separate them?

So will this completely break a project that heavily used the 5.0 sprite swap? Will there be an upgrade path that isn't incredibly tedious and prone to problems?

Also, will there be an easy way to find by label in code?(or a way at all; I know how obnoxious searching for an animator state by hash is)

(If you were going to break everything anyway, why not an integer index that could be easily keyframed without breaking additive layers?)

I don't quite understand how allowing sprite assets being added from outside the file requires removing the ability to easily just convert a layer group in a psb into a sprite library with one click in the sprite editor.

So I have hats in multiple files, what is the preferred method for setting up the rigging to make them work seamlessly? Would I copy the skeleton from the original sprite into every hat file or is there a better way?

 

This change has got me incredibly frustrated. I could set up a new import from Photoshop with a few clicks. Now it seems we have to put everything together manually.
I don't understand the removed functionality for people using PSBs

 

I meant that I was worried that an old project would stop working when upgrading. Though if the resultant data is unchanged, that raises the question of why why the added functionality of the PSB importer can't remain. It wouldn't hurt anyone not using it. If anything, it would be nice to expand that functionality to other import options rather than take the feature out for those using it.

So I finally gave it a try and... well, frankly, I can't see why this would be seen as an improvement. Like Bazeragi said, you could set up a new import with a few clicks before, and now... you can't.

The workflow would be to have an option in the sprite editor UI to instantly create groups with all the sprite resolving taken care of. All the work would be already done in photoshop through grouping layers, so there is no real reason to do it all over again except less conveniently.

Let's say I have a PSB file that has four eye variations, a dozen mouths, three versions for each hand, and maybe a couple other misc. swappable pieces. That would be really easy and fast in 5.x, without even needing to leave the sprite editor.

The basic issue is that that grouping information is in the file already and it is really handy to not have to go through a laborious process with adding components to each element to replicate a one click operation.

Imagine if the FBX importer suddenly required you to manually add a 'bone' component to each bone in a skeleton and then manually enter which mesh to bind it to. That would be absurd, right?

 

In the current version, I could simply

• import my PSB,
• copy over the bones,
• apply meshes & weights,
• select all the layers in sprite skinner & right-click to convert them all into groups/categories

& it would auto-create & apply the sprite library & add all the resolvers for each category.
But it seems that with the newer versions that are in beta, this ease of automation has gone?
Unless I'm missing something, as far as I can tell I have to set up the sprite library myself, add the script to handle it & build up the character & add all the resolvers manually?
If there is a better, more automated way in the new version, please let me know, but I couldn't work it out.
Thanks, Ted!

 

As for supporting other software, that is definitely a good idea- but do any psd exporters that support layers not support groups?

Personally, I think that using something like an (optional) naming scheme for automating things(like is available for multi-file fbx imports) would be better than relying on the finicky psb metadata, but that's already been floated a bunch of times as a suggestion.

 

@Ted_Wikman

My PSB has many sprites I want to switch such as open left eye, open right eye, close left eye, and close right eye.
I imported the PSB and created bones and geometries.
Now, I want to switch these eyes with Unity's Animator or my own scripts.
But, since Unity removed the Categories and Labels features from PSD importer, it seems I have to unpack the original prefab which the PSD importer automatically creates and delete some GameObjects I want to hide.
In this case, I have to delete left and right close eyes' GameObjects from the prefab to hide them.

But if I unpack the prefab to be able to switch the sprites, then I have to reattach all scripts I want to attach each time I make changes on my PSD file.
That sounds really tedious to me because I attached many hinge joints to my sprites so that my character's hair moves with AreaEffector2D or something like that.

Is there any ways I can keep the automatically-created prefab packed and updated automatically even if my PSD has been changed?

Any question is welcome if my explanation is unclear.

 

I understood the current workflow of Unity 2D.
For now until releasing my app, I attach my new scripts which disable and hide GameObjects in the prefab like my own custom Sprite Resolver so that I don't have to unpack the prefab and keep the structures and geometries automatically-updated by PSD importer.

When I release the app and I really need to optimize my app's performance, I will remove my temporary Sprite Resolver, and unpack the prefab and delete some unnecessary GameObjects.

Thank you for your advice! @Ted_Wikman
I hope Unity dev team come up with a good idea about this issue!

 

Hello,

I'd just like to give some feedback on this topic.

I only recently noticed the change in 2021, and it's insane how much more time it takes to set up now versus how it was in 2020. Being able to set categories and labels inside of the skinning editor was very fast and felt very clean. Having less assets in my project window and keeping everything contained in each PSB was nice.

However the above is nothing compared to having to manually add each sprite to its label, and then manually add SpriteResolver components to the necessary game objects. I generally have around 20 parts that need swapping per character so this time really adds up. Also, adding new parts to your character down the line is also more time consuming now.

On top of that, in 2020 adding sprites to a category would merge every sprite into a single game object which was very convenient. As far as I know, that is no longer possible, and I have 4-5 game objects per category that are completely unnecessary, but can't be deleted due to being children of a prefab instance.

It would be really nice to be able to choose which method you'd like to use; either setting categories/labels in the skinning editor like what was possible in 2020, or doing everything manually.

Thank you.

 

I was just following tutorial on Skin swapping and got to the part about categories and labels, and that's what led me here. I think I'd like to echo what everyone is saying that the old method seems a lot better than that giant explanation of how to make it work in the new system.

I had tried to do skeleton sharing before, but that isn't as simple either. As the skeleton works fine, but I need to then go in and re-apply my IK to all of my limbs, as that is done outside the Skinning Editor. And skeleton sharing doesn't have the cool ability this old functionality had of swapping out different body parts on the fly, which I was excited to use for my game.

I really feel like the old functionality should be added back in for future releases, because it's a much more user friendly and useful feature. And I'm an artist, who doesn't code, so solutions that require me to code on my own are a pain, because then I had to ask my programmers to jump off their tasks and make me a tool that used to be built in.

This is very frustrating.

EDIT: I did go through the documentation for the new method. And was more easily able to understand the new method. It does, work though it's a bit clunky. I'm also on 2021.3.16, so I'm using Animation v6, without the Library Editor, which does look to improve the UX.

 

The original workflow was very simple.
I would put a sequence animation character that needed to be rigged, like a slime enemy, into a psb file.
It was bone-driven in its normal state and showed the death process through a sequence when it died. It used to be a simple operation, but now it has become two to three steps.
You have to configure the replacement library manually, and then hide excess layers.
I can give many examples like this. So why can't it be compatible with the previous editing method?

 

Hey, thanks for the info.

I saw this post a few weeks ago, but didn't have the time to properly test 2022's new features. I did have time today, so I decided to download the latest version of 2022 and give it a spin.

It's not great.

List of everything slower and more inconvenient than 2020's PSB workflow:

1. Takes way longer to set up categories and labels (skinning editor was much faster).
2. I have to manually delete extra sprites (2020 merged all sprites that were in a category together for me).
3. I have to manually add the library, and then add resolvers to every sprite I want to swap.

I would greatly appreciate the old skinning editor functionality for creating categories and labels. It was near perfect. I don't see why it can't be added on as an additional way to do things.

 

I too seem to have discovered this great feature after it is already being discontinued. The docs are still pretty sparse on the workflows for the newer versions and all the tutorials I'm finding rely on the PSB import working as it did in 5.x. I tried both the 2021 and 2022 versions and while the 2022 version does have a drag and drop that tries to build categories for you it uh...basically works the reverse of the way people coming from 5.x would expect it too.

It doesn't take grouping into consideration at all and instead uses the bottom level layer name as both the category name and the label name. Since it can't have two labels with the same name in the same category and doesn't even try to increment the labels it overwrites any layers where the final name is the same(I would have at least expected it to import both layers in the same category and increment their labels). You have three layers named 'mouth' then there is one category 'mouth' with one label 'mouth' in it and it is arbitrary which of those strites get kept. You have three layers 'Mouth1', 'Mouth2', and 'Mouth3' then you get three categories with the same. This means that there isn't a way(that I found or the documentation reveals) of structuring your files so that they will import multiple sprites into the same categories. Not only that, if you separate it out into two PSB files, then try to import the second file, it completely overwrites anything that matches from the first.

There was definitely a loss of functionality when going from 5.x to 6.x, and I feel like the drag and drop tooling for PSBs was an honest attempt at meeting halfway, but it doesn't quite make it off the porch. It at the very least needs to increment the labels for matching category names. It still wouldn't function as intuitively as the old importer did, but then you could at least use it to import more that just one set of sprites ever. OPTIMALLY there would be a way to specify a different Category name and Label name through the PSB file structure, for example having the group name be a category and the layer name be the label name.

The packages say they are release versions, I presume the reason none of this was caught in beta is most people using these features would rather stay in unity 2020 then deal with these issues, so it hasn't been getting tested. Honestly, I'm debating if I want to roll back to 2020. I just started this project and am going to have to do a lot more work in the more recent versions than I would if I rolled back, imported everything where the PSD importer works fully, and then upgraded the project back to the latest. That is if like you say, upgrading the projects doesn't pooch currently set up rigs and sprite swapping.

 

Exactly.
The ability to automatically convert the names of layers into groups and labels when importing
-is the BEST that was in the animation package to reduce manual labor.
But now it is lost.

 

Currently the drag and drop functionality does not support multiple sprite going into the same category, among other things. Is there a way that the import process can be hijacked by devs to make it work for their needs without writing an entire importer from scratch? The importer is very close to usable and I doubt it would take much to fix it if we had access.

If there is not a way to inject steps into the process, is there an API exposed that would allow us to write code that interacts with the sprite library? My rollback idea did not work and at the moment it looks like I either need to write my own importer or go buy Spine if I want this functionality in the newer versions of unity.