Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Dynamic Skins in C Runtime

Westquote

Hey all,

In the project I am working on, there are multiple character variants on-screen at the same time, and I need to generate/modify skins dynamically at runtime. In particular, this involves randomized face/body/outfit swapping, as well as held-item swapping. Each item shares the same animation data, but is itself composed of multiple different skinned mesh attachments that have slot attachment animation keys. In order to permit these item mesh sets to be swapped around at runtime, the attach keys use placeholders, not concrete attachments.

Everything appears like it can be set up correctly from within the editor, but I am having trouble figuring how to implement the runtime aspect of this feature.

Specifically, I am working in the C runtime, and I am not certain how best to go about creating a dynamic skin at runtime that will assign the placeholder values with concrete attachments (for keyed slot attachment animation).

Based on my knowledge of the runtime, my expected approach was:

Create a new spSkin.
Copy all attachments from an specified existing skin (most likely "default") into the new skin.
Rename or copy desired attachments within the new skin to the names of the placeholders.
Call spSkeleton_setSkin(skeleton, skin) on the skeleton.
Update the skin attachment and call spSkeleton_setSkin again whenever the held item or outfit changes.

I can see a number of other possible approaches to this task, but all of them run into the same issue, which is an apparent inability to deep-copy a skin/attachment instead of simply referencing it. According to the source code, the spSkin owns its attachments (calling dispose on them), which means I cannot safely share the attachments them between multiple skins. Moreover, the skin's entries are private data, so a deep copy solution appears to be strongly and explicitly discouraged.

Is there a way you would suggest implementing this feature? My hope is that I'm misunderstanding the usage idiom, and that there is a safe and straightforward way to accomplish what I need. (I am reluctant to take the brute-force approach of intrusively implementing a spSkin_clone(), spAttachment_clone() function, etc..., as the propagation of vtable changes alone would create a significant maintenance hassle when integrating future Spine versions.) An alternative approach would be to have a placeholder name-aliasing system per-spSkeleton that indirects attachment names through a lookup table.

Let me know what you think! 🙂

Thanks,

Tim A.

P.S. Here is a stack of pancakes doubling as a birthday cake: :cake:

jpoag

Have you seen the Goblins example that switches between goblin girl and guy while having multiple attachments for the hands? The default skin has a "left hand item" and a "right hand item", the left hand item being swappable between a dagger and spear. This swapping persists using spSkeleton_setAttachment, even after calling spSkeleton_setSkin because the new skins don't have slot definitions for "left hand item" or "right hand item."

The spSkin lives in the Skeleton Data which is shared among skeleton instances.

You could conceivably have a default skin with a shared set of attachments, class skins that override only specific slots with multiple attachments per slot. The default is the first attachment in the slot attachment list, but you could randomize using spSkeleton_setAttachment. I might even have code laying around here somewhere to grab the list of available attachments for a slot...

So use spSkeleton_setSkin to select the class, then use spSkeleton_setAttachment on each slot that needs to be randomized.

https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-cocos2dx/2/example/Resources/common/goblins-mesh.json#L50

BinaryCats

Hi,

Although you talk about dynamic skins, from what you have wrote, I am assuming you just want to beable to switch skins on the fly, and not create them.

the standard way you seem to be talking about is to call spSkeleton_setSkinByName(skeleton, skinName) with skeleton being the, well, skeleton you want to impose the skin onto.

However, this has various issues if some skins use slots that others don't. We use something similar to:

spSkin * skin = spSkeletonData_findSkin(skeleton->data,skinName);
([i](spSkin[/i]*)&skeleton->skin) = skin;

for (int i =0; i < skeleton->slotsCount; i++)
{
   spSlot * slot = skeleton->slots[i];
   spAttachment * attachment = spSkin_getAttachment(skin,i,slot->data->attachmentName);
   if(attachment) 
   {
      spSlot_setAttachment(slot,attachment);
   }   

   else
   {
      spSlot_setToSetupPose(slot);
   }
}

which solves the problem.

Westquote

Thanks so much for the info! These approaches sound close to a good fit for what we're doing, though I'm not totally clear on how this will work correctly with keyed slot attachment changes. Looking at the code, it looks like keyed slot attachment lookups route through the skeleton, and in doing so check (by name) in both the active and default skin to determine which attachment to set. Because of this, I'm concerned that any manual calls to spSlot_setAttachment will be wiped away as soon as the first slot attachment key for that slot is evaluated (and calls this very function itself).

The use case we have is:

1) Flipbook-style animation of meshes for each weapon, with animations shared across multiple weapons (each with different art).
2) Randomly-assembled paper-doll characters that also contain spAttachmentTimeline-controlled slot attachment keys.

Because of this use case, we are using placeholders in our animation data to make the animations themselves generic across the many concrete weapon and character-pieces meshes. I have not found any way to "assign" a concrete mesh into a placeholder mesh slot, though it seems like it would be trivial to do so by creating a simple system that aliases a placeholder name to a concrete mesh in the default skin?

Please let me know if I'm missing something such that the solutions provided might work for our use case after all - it's clear there are many powerful and different paradigms one can use when structuring a character for dynamic manipulation.

Thanks! 🙂

Tim A.

jpoag

Yeah, as soon as you hit a keyed attachment frame it'll switch to whatever is defined in the skin. I guess it all depends on what you want to happen when it hits the keyframe: change to a related attachment or stay the same.

The other idea is to select the attachment you want during the draw phase. When you are iterating the slots, you grab an attachment and if not nullptr, you have the attachment->name .... or slot->name, or both. You could simply lookup the name in an std::map<std::string, spAttachment*> for the animation to see if it has an override. In my engine I use both (plus a third option of native objects using the slot transform).

Remember that during the drawing phase the attachment is generating the geometry based on the slot->bone. The attachment doesn't retain its own state, so you could share one copy of the attachment with as many animations as you want.

It makes sense to include the attachment in the spine animation for things like mesh attachments that have complex, weighted animations. So really, there would be skin 'classes' that retain whole sets and your engine code would permutate the combinations.

Westquote

The draw phase redirect sounds perfect for my needs. Thanks again for your help with this! 🙂

Tim A.