![]() You can look at SkeletonJson where it calls AttachmentLoader#newRegionAttachment. 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.Īs far as how to create an attachment, sorry I don't have an example on hand. You can't rotate your attachments to reduce wasted space. This approach is nice because you can add more and more attachments without any work in Spine. ![]() Once you have the attachment, you'll likely put it in a skin as Pharan described. At runtime you create a new attachment, using the offset from the single attachment positioned in the editor. 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). 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. ![]() 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. But I think they did say they'd get to it since it's pretty standard.It's not exactly hard to manage today. 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. So you can update it even after you've called SetSkin.īut 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. Note that SetSkin assigns the skin object to the skeleton persistently. (5) call yourSkeleton.SetSlotsToSetupPose() For each slot+skin placeholder you need to set an image to. (3) call yourSkin.AddAttachment(yourSlotIndex, yourSkinPlaceholderName, yourAttachmentObject). (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. In actual implementation for your game, you'll need to follow what CustomSkin.cs does. You just need to be aware of what things you need so you can add them in the editor and use them at runtime.).īut any of the Spine runtimes can handle it.įortunately for you, since you're a Spine-Unity user, a sample has been implemented and is part of the Spine-Unity unitypackage.ĬustomSkin.cs is a component/MonoBehaviour that you add to your GameObject that has a SkeletonAnimation/SkeletonRenderer on it.Īt runtime, CustomSkin will generate a custom skin for you and allow you to use any existing attachments you pick in the Inspector. ![]() 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 can prepare all the attachments you need in the editor so the alignments are correct and reliable. 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.
0 Comments
Leave a Reply. |