Spine Attachment as public variable

RemDust

Hi guys ! :hi:

I've been setting up my Item/Inventory system these days and now I'd like to get a public reference to specific Spine attachment on my weapons (which derived from ScriptableObject).

I actually don't think that what I'm asking is possible but it would be really great for us to be able to set the attachment as a property. :rock:

What I really try to achieve is something like :

each Inventory Slot is "aiming" at a specific Skeleton Slot, and throwing a weapon in that inventory slot will display the correct attachment in the right "skeleton place".

For instance : if you throw a sword scriptable object in Helmet inventory Slot, it would call a method that get the public reference to that specific sword attachment and play it in the correct Spine Weapon Slot.

Pharan

Attachments are pretty public. You can get them from a variety of places. Skeleton.FindSlot.Attachment or Skeleton.Skin.GetAttachment or whatever. And they're classes so they are also reference types.

Did you mean an Unity serializable/inspectable field?
If so, then no. These are defined in spine-csharp which is shared among other C# game engines. Unity limits those to certain types (like GameObjects, components and assets).

If not, you should know that Attachment references are stored in Skins (which are dictionaries). So you can access Attachments through your SkeletonData where all the "stateless" objects live, use SkeletonData.FindSkin and then Skin.GetAttachment. The GetAttachment method requires both the slotIndex and the attachment name since attachments on different slots can have the same name.

Your system may benefit from an alternate setup though, before you're too fixed on a certain way of doing it.
I recommend you check out the "Mix and Match.unity" sample scene that comes with the spine-unity.unitypackage.

RemDust

Thanks Pharan, yep I meant Unity Serialized fields, but I didn't really expect it to be possible ^^

I'll take a look at the "mix and match" sample 🙂

Pharan

You could always serialize the strings and update the skeleton accordingly if you want visual feedback. That would be your own custom editor script for your game.

RemDust

That's what I was thinking about, having an int and a string fields on my Weapons objects so I can pretty much set that up in Unity inspector. 🙂

The only flaw with this GetAttachment method seems to be you have to be really careful if you create new skins later on since the index can change, right ?

Pharan

The slotIndex can change, sure. That's why you would serialize your slot names rather than your slot indexes.
Then just find the slotIndex at load time, or on the fly in the editor, and use that on your Skin.GetAttachment call.

RemDust

Hi Pharan 🙂
I took a look at the mix and match Unity exemple but I got to confess that the scripts are pretty confused to me ( I'm not a strong developer, obviously ! )

As far as animating goes (and regardless of the Unity side of things) which setup in Spine would you advice for a "mix and match rpg inventory" system ?
I'm aiming at something like "dark warrior armor set" which contains different pieces that you can find and mix/match with lets say another "leather archer set".

What I (think I) have understand so far :

a skin would be an armor set (dark, leather)
each slot would contain placeholders (body, head)
placeholders would contain skin attachments (magic jacket, helmet of assHead)
attachments who needs to be "mesh deformed" should be linked to a "default master mesh" (default helmet would share his mesh deformation to any other helmets)

Now there is one thing that still puzzles me :
In the goblins setup, you did use skins to switch between goblin/girl (which could be my armor sets) but you didn't use skins for weapon switching ?
In all this, I also need to use my (already animated on slot images... -_- ) meshes deformations.

I'm a little bit lost as you can see ! ^^

Am I right so far ?

Pharan

That's right.

And yes, the goblin sample is very old. It uses the Skins feature for different characters. It didn't involve any equip system.

A Skin at runtime is just a place where the skeleton keeps its attachments.
When a skeleton is animated, asks can ask a Skin, "give me the helmet attachment for slot 3". And a dark warrior Skin can give it the dark-warrior-helmet attachment.

A Skin Placeholder in Spine is just the name stored in the skin. In the above example, it would be "helmet".

The skeleton's skin is kept in Skeleton.Skin. You can change it by saying:

skeletonAnimation.Skeleton.SetSkin(yourNewSkin);
skeletonAnimation.Skeleton.SetSlotsToSetupPose();
skeletonAnimation.Update(0);

The skin system works in a plain way like how it's used in the goblins example.
But can also serve an equip system if you create a custom Skin, and set the individual attachments.

eg. "I want helmet for slot 3 to be leather-archer-helmet. sword for slot 5 to be dark-warrior-sword".
That's what the mix and match custom script is doing.
The other half of the mix and match script is just showing different ways of getting an attachment to put in that skin. You can get it from an atlas, from a Unity Sprite, from attachments in existing Skins, or as a new linked mesh from an existing mesh if you want animated deformation.

RemDust

Thank you for the detailed reply Pharan, as usual 🙂

Pharan wrote
You can get it [...] as a new linked mesh from an existing mesh if you want animated deformation.

And to do that I would just get the linked mesh (created in Spine editor) like any other attachment ? By the methods you previously described ?
We're not talking about creating a new mesh runtime and link it by code ?

Hopefully we're getting there, sorry for being so noobish :whew:

Pharan

Yes, that's what this line means: spine-runtimes/MixAndMatch.cs at master

In summary:
(1) Make and animate a mesh in Spine
(2) Get the mesh at runtime using GetAttachment
(3) Make a new linked mesh that's linked to it using GetClone(true);
(4) change the image using SetRegion
(5) add that new linked mesh attachment to your custom skin using Skin.AddAttachment

RemDust

Thank you so much, It is MUCH clearer now ! 🙂