Attachments names - not unique?

jcmeyer5

So I am working on a run time, and one of the assumptions that I wanted to make (based on documentation of the file format) is that no two attachments would have the same name. I get that from this:

Common attachment attributes:

name: The attachment name. This is unique for the skeleton. For image attachments this is a key used to look up the texture region, for example on disk or in a texture atlas. If omitted, the key from the surrounding JSON map is used as the actual attachment name.

So as an experiment to (hopefully) backup my assumption, I took an image, and was able to add it to multiple slots, and have it displayed at the same time. In the JSON, it also has the same name.

So could I get a bit of clarification on what "unique for the skeleton" means? I am guessing it should be "unique for the slot" instead.

jcmeyer5

Nate

It used to be for the skeleton but that restriction was changed. I'll update the docs, thanks!

The attachment name doesn't have a uniqueness restriction. However, the names used as part of the key for a skin entry are unique per slot.

jcmeyer5

Gracias.

Working with skins. When I have two region attachments on one slot, how do I know which one to load when I load the skin?

jcmeyer5

Another issue... if I have a bone of 0 length, and I scale it, the attachment does not scale... but the attachments on bones that call that bone parent DO scale. For instance, if my root is a pelvis, and I have attached bones for the legs, and all three bones have region attachments, if I scale the pelvis (root) the attachments on the legs will scale, but the attachment on the root (pelvis) will not. That seems odd.

Nate

Not sure what you mean "when I load the skin". The skin is a mapping of slot+name to attachment. When you load the data (eg textures) for an attachment is separate. You can load them up front or lazily.

A bone with zero length is no different than a bone with a length. When a bone is scaled, the attachments and child bones should be scaled.

Any reason why you don't extend one of the official runtimes? 🙂

jcmeyer5

Nate schrieb
Not sure what you mean "when I load the skin". The skin is a mapping of slot+name to attachment. When you load the data (eg textures) for an attachment is separate. You can load them up front or lazily.

Okay.... so for a skin, I can have two attachments on one slot. So for eyes, I can have an eyes open and an eyes shut. See here:

	"skin1": {
		"eye_SLOT": {
			"eye1_SKIN": { "name": "eyesOpen", "width": 49, "height": 20 },
			"eye2_SKIN": { "name": "eyesShut", "width": 49, "height": 20 }
       }

So when I am pulling apart the JSON, what tells me which attachment to show?

Nate schrieb
A bone with zero length is no different than a bone with a length. When a bone is scaled, the attachments and child bones should be scaled.

Right. Implementing the export file, it works as intended. In the Spine app, the attachment to that bone did not scale, but the other attachments on children bones DID scale. It is a display quirk with Spine I think.... not a problem with the file layout.

Nate schrieb
Any reason why you don't extend one of the official runtimes? 🙂

I enjoy building these things. It is a personal project. It is helping me learn JSON and more about dictionaries, arrays, etc.

Nate

Ah, the setup pose attachment is specified by the slot.
http://esotericsoftware.com/spine-json-format/#slots

I've never seen an attachment not scale with the parent bone in the editor. :o

Fair enough, it's definitely neat to finally get your skeletons displaying as they should. 🙂

jcmeyer5

I am going to ask this again, as I may not have been clear before. I will use an example to do it.

Say I have an animal skeleton. I have several skins for this animal skeleton... a lion, a tiger, and a bear. Each has its own set of eye images... angry eyes, open eyes, closed eyes, dead eyes. When I build this skin, I will have an attachment for each. When I load that skin, how do I know which one is loaded?

OR... are you saying that the name of the default attachment when setting up the slot is the attachment I should look for in the skin (not default skin)? Is there a naming consistency that I need to adhere to? What if different skins have different default eyes... the tiger has cute eyes by default, the bear has angry eyes by default, but both skins have cute and angry eyes?

Is any of this making sense?

Nate

jcmeyer5 schrieb
Say I have an animal skeleton. I have several skins for this animal skeleton... a lion, a tiger, and a bear.

A lion, a tiger, and a bear? Oh my! :tmi:

Each has its own set of eye images... angry eyes, open eyes, closed eyes, dead eyes. When I build this skin, I will have an attachment for each.

That last sentence lost me, because you don't have just one skin.

You'll have an "eyes" slot with skin placeholders: angry, open, closed, dead. Then you'll have 3 skins: lion, tiger, bear. In the lion skin, the angry skin placeholder for the eyes slot will use the lion-eyes-angry image, the open skin placeholder will use lion-eyes-open, etc. In the tiger skin, the angry skin placeholder for the eyes slot will use the riger-eyes-angry image, etc.

When I load that skin, how do I know which one is loaded?

This also isn't clear. When you load a skin from JSON, it is just a mapping of slot+name to attachment. Eg your lion skin will look like:

eyes slot + "angry" = lion-eyes-angry attachment
eyes slot + "open" = lion-eyes-open attachment
eyes slot + "closed" = lion-eyes-closed attachment
eyes slot + "dead" = lion-eyes-dead attachment

When you set a skin on a skeleton, it just changes where it finds an attachment. Eg if you set the lion skin and then use Skeleton#setAttachment("eyes", "closed") then it will find the lion-eyes-closed attachment.

Each SlotData has an attachment name that is the attachment to show for the setup pose. If the "eyes" slot has "dead" shown by default, the if you set the lion skin and then call Skeleton#setSlotsToSetupPose(), it will use the lion-eyes-dead attachment for the eyes slot. If you set the tiger skin and then call Skeleton#setSlotsToSetupPose(), it will use the tiger-eyes-dead attachment for the eyes slot.

OR... are you saying that the name of the default attachment when setting up the slot is the attachment I should look for in the skin (not default skin)? Is there a naming consistency that I need to adhere to? What if different skins have different default eyes... the tiger has cute eyes by default, the bear has angry eyes by default, but both skins have cute and angry eyes?

Yes, the SlotData is a name to use for looking up an attachment. It doesn't care what names you use, use names that make sense to you. Different skins cannot have different default eyes. You will have to set the skin, then set the eyes you want.

Make sense now? 🙂