Unity - Dynamically Create Attachment Example

newcomma

Hi There,

I want to dynamically create an attachment at runtime from a texture in Unity, but I'm not exactly sure how to do this (other than knowing it can be done). Are there any tutorials or guides demonstrating how this can be done easily in code?

The AtlasAttachmentLoaders seem to require that the texture is pre-existing in a Spine texture atlas, is this a requirement for creating new attachments? Would I be unable to create an attachment directly from a texture?

Does that in turn mean I need to dynamically create a spine atlas at runtime from the textures I wish to include (And is this possible?)

My texture resource is configured as a Sprite type (not sure how relevent this is),

I'm fairly new to understanding the run time at all so would appreciate any advice

Thanks

Pharan

The answer to your need to mix and match items to customize a character is not to dynamically create attachments at runtime, but to dynamically generate a Skin, which is just a wrapped Dictionary of skin placeholder names and attachments.

You can prepare all the attachments you need in the editor so the alignments are correct and reliable.

This is not a feature that the Spine runtimes were designed with yet (as there are no features that support it in the Editor. You just need to be aware of what things you need so you can add them in the editor and use them at runtime.).
But any of the Spine runtimes can handle it.

Fortunately for you, since you're a Spine-Unity user, a sample has been implemented and is part of the Spine-Unity unitypackage.

CustomSkin.cs is a component/MonoBehaviour that you add to your GameObject that has a SkeletonAnimation/SkeletonRenderer on it.
https://github.com/EsotericSoftware/spi ... tomSkin.cs

At runtime, CustomSkin will generate a custom skin for you and allow you to use any existing attachments you pick in the Inspector.

In actual implementation for your game, you'll need to follow what CustomSkin.cs does.
(1) Make a new Skin object.
(2) Prepare the name of the slot (2) the name of the skin placeholder and (3) the name of the different attachments (variations of hats, or shirts or whatever) under the slot.
(3) call yourSkin.AddAttachment(yourSlotIndex, yourSkinPlaceholderName, yourAttachmentObject). For each slot+skin placeholder you need to set an image to.
(4) call yourSkeleton.SetSkin(yourSkin)
(5) call yourSkeleton.SetSlotsToSetupPose()

Note that SetSkin assigns the skin object to the skeleton persistently. So you can update it even after you've called SetSkin.
But whenever you change something in that Skin object (whether you add or change attachments), you need to call yourSkeleton.SetSlotsToSetupPose() so that the attachments refresh.

newcomma

Thanks for the response, the downside of the approach being entirely dirven by the editor is that if the number of items grows it will become a bit of a pain to manage it through the editor.

Let's assume we start with 10 hats, then artists make another 90, ideally rather than changing the spine character from Spine, I would dynamically instance these as needed. This would allow the number of mix & match items to increase without increasing the editor complexity with setup.

If attachments can be constructed from a texture at runtime and added then this would be perfect.

Pharan

Doing it in the editor is still easier because you need to align the damned things.

If you don't want 100 hats in the editor, you'll need to find out what attachment offset and rotation values you need to use to align each variation correctly with the rest of your character, write all this information down and maybe keep them as a separate (new) data structure that you need to use at runtime to generate new attachments. Tell me that isn't a pain to manage.

Regardless of that, dynamically generating a Skin is still a reliable way to implement mix-and-match. Dynamically generating attachments is something you do on top of this, if you choose to.

That said, the reason why ease of management doesn't scale up to 100 items is because it's not an official feature yet. But I think they did say they'd get to it since it's pretty standard.

newcomma

Can you explain the alignment problem in a bit more detail if possible?

I mean presumably if the art is always kept to the same relative rotation and pivot point then it doesn't matter which hat needs to be attached, they can all use the same offset/rotation? Or am I missing something fundamental here?

Without wishing to devovle the discussion too much, I'm still a bit unsure as to whether it is possible to create an attachment from a unity texture at runtime / if there are any code examples?

Nate

Pharan wrote
This is not a feature that the Spine runtimes were designed with yet (as there are no features that support it in the Editor. You just need to be aware of what things you need so you can add them in the editor and use them at runtime.).
But any of the Spine runtimes can handle it.

The runtimes support it because they were designed specifically with the feature in mind. 🙂 There aren't any editor features required.

Pharan wrote
That said, the reason why ease of management doesn't scale up to 100 items is because it's not an official feature yet. But I think they did say they'd get to it since it's pretty standard.

It's not exactly hard to manage today. What did you have in mind to make it easier to manage 100+ attachments in the editor? Having so many attachments is always going to be a bit of a pain.

If you have many attachments and want to avoid specifying the attachment offset for each in the editor, then you could attach one of each in the editor and create the others dynamically. You'll need to design your art in such a way that all attachments can use the attachment offset of the single attachment in Spine (for each slot). At runtime you create a new attachment, using the offset from the single attachment positioned in the editor. Once you have the attachment, you'll likely put it in a skin as Pharan described.

This approach is nice because you can add more and more attachments without any work in Spine. It has a few downsides. It's more complex to setup. You can't rotate your attachments to reduce wasted space. If you use a single image per attachment, you'll have many draw calls, so likely you'll want to dynamically generate a texture atlas at runtime with only the images you need.

As far as how to create an attachment, sorry I don't have an example on hand. You can look at SkeletonJson where it calls AttachmentLoader#newRegionAttachment. You need to do everything newRegionAttachment does (which is renderer specific loading), plus the code immediately after that call in SkeletonJson (which is storing data from the JSON on the attachment). Whatever object in the attachment loader that will be needed for rendering (texture, material, atlas region, etc) is stored in the Attachment#rendererObject field. The renderer gets this out, making an assumption of what it is by casting it, and then draws using it as appropriate. You can stick anything you want into the rendererObject and then customize the renderer to handle it.

Pharan

Nate wrote
The runtimes support it because they were designed specifically with the feature in mind. 🙂 There aren't any editor features required.

Mix and Match isn't an official feature like Skins are. It's not something explicitly described in the docs or in the editor's UI. There's no clear way to do it.
The editor doesn't allow the animator/artist to view combinations to see if they work or if it has problems. You'd have to have the programmer whip something up for you. I mean, Spine technically does allow you to switch images around in setup mode. When you have animations that switch attachments, you can't do stuff with it.
Even if you're both the artist and the programmer, it's unclear. You'd need to rummage around the code and do trial and error stuff to do it. That's not what an official feature is.

Nate wrote
It's not exactly hard to manage today. What did you have in mind to make it easier to manage 100+ attachments in the editor? Having so many attachments is always going to be a bit of a pain.

Having 100*something items in the tree causes it to be ridiculous to work with. If the image/attachment list could be viewed separately from tree navigation, it would scale better to 100+. I think this is what the image picker can eventually do.

I've done the whole turn-on-and-off-bones-slots-and-attachments ninjutsu in the tree when I did multiple skeleton hierarchies in one skeleton and it's a headache.

newcomma wrote
I mean presumably if the art is always kept to the same relative rotation and pivot point then it doesn't matter which hat needs to be attached, they can all use the same offset/rotation? Or am I missing something fundamental here?

It's as Nate described. If— for example, for hats— you just made hat images that all had the exact same height, width and "pivot", you could have one set of offset values for all hat attachments. You would then just need to copy the values from the original hat in the editor.
You wouldn't be able to make hats that are bigger than that hat. You'd be wasting space in some cases if you had some shapes.

This is under the assumption that you'd pack your extra images in a libGDX atlas, like normally exported Spine projects.

If the key feature you want is to be able to generate a new attachment from any Unity texture at all, I don't know where to start.
I'm sure it's possible to hack it in. You just need to feed SkeletonRenderer data it understands.
But I've never done it and I don't have samples for you, sorry.

These aren't your only options though. You could also just add them as regular unity sprites, and attach them to bones using SkeletonUtility or something. Sorting will be your main problem there.

newcomma

This is under the assumption that you'd pack your extra images in a libGDX atlas, like normally exported Spine projects.

Thanks, just to clarify, am I right in thinking the libGDX atlas can be generated via https://code.google.com/p/libgdx-texturepacker-gui/?

Is there a concern if the generated atlas may differ based on which version of libgdx-TP is included within spine?

These aren't your only options though. You could also just add them as regular unity sprites, and attach them to bones using SkeletonUtility or something. Sorting will be your main problem there.

This sounds pretty interesting, would you be able to clarify what the approach here would be? Would it be essentially doing something along the lines of:

Object hat.setPosition(SkeletonUtility.utilityBones.FindBone("HeadBon").transform)

I guess the major downside to this is that you wouldn't be able to batch the draw calls for the skeleton in this manner easily. Additionally if the character is animating I'm unsure as to whether there may be timing issues for updating the unity transform position against the desired attachment position. Additionally I guess this may be less performant. Perhaps insignificantly.

you just made hat images that all had the exact same height, width and "pivot", you could have one set of offset values for all hat attachments

Does the height/width need to be identical for identical attachments? If width/height is stored per image then presumably the region that gets constructed can be of variable dimensions, or is this what breaks the correct offset/pivot pointing.

Nate wrote
If you use a single image per attachment, you'll have many draw calls, so likely you'll want to dynamically generate a texture atlas at runtime with only the images you need.

Based on the assumption that the atlas is required to be in the libgdx format for Spine, utilizing this source: https://github.com/libgdx/libgdx/wiki/Texture-packer

As the libgdx runtime is in java, would this require a c sharp port? Or perhaps a c sharp runtime port for the texture packing exists already? A quick google search isn't proving super fruitful.

Pharan

Sorry, I wasn't clear. Spine's atlases are libGDX atlases. Spine generates libGDX atlases whenever you pack textures with it.
I'm pretty sure Nate is using the exact same packing library they made for libGDX.

You're right. It wouldn't batch. You're also right that it's less performant, but you're also right that it might be insignificant. What may be relevant is how much performance scales the more characters and customizable items you have, which may not be an issue if you don't have that many.

newcomma wrote
If width/height is stored per image then presumably the region that gets constructed can be of variable dimensions, or is this what breaks the correct offset/pivot pointing.

Yes, that's what breaks the pivot/alignment.
If you want variable sizes, you'll have to figure out how to make the pivots easy to define and easy to check if they're passable. You will need some extra math when generating attachments AND creating/painting assets, or you have to manually align them in the editor.

newcomma

Cool thanks Pharan,

So just to check, is it impossible to dynamically create the libgdx Atlases spine requires at runtime, as there is no Csharp/Unity libgdx TexturePacker runtime available to generate these with?

Pharan

It's theoretically possible because of two things:
(1) Unity can generate textures at runtime (especially now that Unity 5 has no limitations).
(2) Unity can generate text assets at runtime. But more practically, it could also directly generate the deserialized version of a libGDX atlas (not the text form).

You probably don't really need a libGDX atlas. But if you did need one, you could generate one. But you really just need a format that SkeletonRenderer understands.
You just have to figure it out. It's not something I'm familiar with in detail so I can't guide you farther than that.

Nate

Pharan wrote
Mix and Match isn't an official feature like Skins are. It's not something explicitly described in the docs or in the editor's UI.

There are a great number of approaches that could be taken to build games. Some are less common and/or don't yet have editor features. Some happen solely at runtime and don't need editor features. I'd say something is an "official feature" if the runtimes are designed specifically to enable such usage. However, I don't think this "official feature" terminology is really helping anyone. Better to explicitly say what is lacking if something is lacking, eg that editor could do more to let you visualize mix and match.

Having 100*something items in the tree causes it to be ridiculous to work with. If the image/attachment list could be viewed separately from tree navigation, it would scale better to 100+. I think this is what the image picker can eventually do.

Having hundreds of items is always going to be a pain. Type-to-filter might help, but it's still a lot of items that need to be positioned correctly and dug through to find the one you want. Every time I sit down to work on the image chooser, a dozen things pop up. :p

newcomma wrote
Thanks, just to clarify, am I right in thinking the libGDX atlas can be generated via https://code.google.com/p/libgdx-texturepacker-gui/?

No! My texture packer doesn't have a UI. I'm totally against a UI for it. 🙂 The packer is here:
https://github.com/libgdx/libgdx/wiki/Texture-packer

However, this isn't a tool you would use at runtime, as it is a heavyweight, offline tool. You would likely write your own simple packing like this (Java implementation here). The Spine runtimes don't require use of the Spine atlas stuff. You can jam anything you want into the attachments and then get it out and render with it in the renderer.

It sounds like you haven't explored with spine-unity can do, I recommend watching some videos or going through the example projects. Positioning a GameObject doesn't have performance problems. It doesn't necessarily have to hurt batching, you would just need to use the same material for your GameObject as you do for the skeleton.

newcomma wrote
Does the height/width need to be identical for identical attachments? If width/height is stored per image then presumably the region that gets constructed can be of variable dimensions, or is this what breaks the correct offset/pivot pointing.

Imagine you have an image that is your sword attachment. It is positioned so the origin of the bone it is attached to is at the hilt. Probably you put a red X in the actual image so when your artist opens the image, they know where the pivot is. To make a new attachment, the artist can draw whatever they want instead of a sword, as long as they keep the pivot at the same location.

If you make the image bigger, what happens to the pivot location relative to the bone? How will the artist know where the pivot is within the new, larger image? You could probably come up with a way to solve these questions, but it is easiest to just use an image that is big enough for all your attachments.

Pharan

@Nate. Forgive my loose use of the term, Nate.
I was also wrong. The docs do describe it: http://esotericsoftware.com/spine-skins#Combining-skins
I guess I should've said "the feature is planned". :p

Combining skins is certainly not the only way to achieve it though, especially when customizable parts/equippable items don't come in sets that make sense to group into skins, but make more sense to group into equipment/part slots. You probably already came to that conclusion anyway. Whenever it's something you already mentioned, I assume it's a discussion you're having with Shiu that needs some time to percolate or congeal into a wonderful implementation idea.

Right now, "Combining skins" is also not the most obvious thing to search for (mix and match is probably not much better, maybe the terms "equips" or "customizable character" should be in there), but it's at least there and we can point to it. That's all I was describing as "not an official feature yet" though.

The dynamic generation of attachment stuff is definitely a runtime thing and specific to each engine.

I remember when I first used Photoshop and it didn't have a "glow" effect.
You had to duplicate a layer, lock its transparency, fill it with a color, unlock its transparency, blur it, then stick it under the layer you wanted and change the blend mode. It was hilarious, but it was hard to tell at the time what could have made it better. 2.5 versions later, the first layer effects got implemented.

Also, the picker needs to show thumbnails with names on hover, and will need to scroll if there's a lot of them, and have a textbox for filtering. :p
And you should be able to key it right there on the popup, just as an additional hint for the people who think the key right next to the slot visibility dot is for keying slot visibility.

Agreed that 100 items will need to be aligned anyway. It's 2D though, 100 hats and 100 swords is a finite amount of work; the kind of inevitable work that animators and artists who already drew 100 hats and swords would expect and are certainly used to much worse (and used to optimizing much worse). The hope is that the tools help make things speedy to do rather than give you 200 tiny things to click on.

My ideal workflow in that situation:
Have all attachments share one offset first.
Then
(1) drag the attachment with a mouse or pen to align it.
(2) press a key to select the next attachment.
(3) Rinse and repeat.

I hope you're getting well, Nate. And I hope these messages aren't giving you migraines. >_>

@[삭제됨]
Sorry to hijack. And sorry again for confusing you on some of those parts.
But yeah, Nate said it.
Best of luck in implementing this. Better read up on stuff.

Nate

Migraine city here. I blame you! :p Left the house for the first time in a week, to eat. Starting to feel better, but only just. :puke:

kirie

Hi~
I have a same issue. May i ask some questions?

Our team are creating prototype of 2D RPG, and researching 2D tools.

We want to change weapon texture when equipped, and we can using skin & attachments.
But when we make another skeleton and export, weapon textures are included each skeleton atlas.

With different gender and races, we want make different bone for characteristic but use same weapon textures.
(e.g human male/female, angel with wings male/female)

We will have 150+ weapons and some common items.
If all item textures included in each skeleton atlas, resource size is too big.
Is there a better way in spine?

Sorry for my poor English.
Thanks.

Mitch

Yes. You can use TexturePacker to generate multiple atlases that are shared between characters. I will make example video 🙂

viewtopic.php?f=7&t=4205

Huge update coming to this. I already pushed changes to the repo and updated the package, but I'll post a video of "How to use new stuff" in regards to dynamically created attachments in Unity.

viewtopic.php?f=7&t=4206