Change Region / Mesh Path at Runtime

fallen

After loading a Skeleton and picking a skin, we are trying to to change the path on a few of the regions / meshes within the skin. The effect we want is exactly what you would get if you clicked on a region attachment in the editor, and typed a different value into the Path field. Specifically, that is important as some of these are linked meshes, and I need to keep the binding / weights.

Is this possible to do with the Spine API?

Should I make a new attachment, copy over all the properties, and then setAttachment on the slot?
Should we modify the attachment loader instead?

Thanks in advance for the guidance on how to proceed!

Here is the code I am using to look up the two types of attachments:

// find a slot with a standard texture under a skin attachment
spSlot* rHand = mSpine->findSlot("Arm - Right - Hand");
spRegionAttachment* rHandAttach = (spRegionAttachment*)rHand->attachment;
// help :)
// find a slot with a linked mesh under a skin attachment
spSlot* legs = mSpine->findSlot("Legs");
spMeshAttachment* legsAttach = (spMeshAttachment*)legs->attachment;
// help :)

I have seen a few other threads about dynamically copying / building skins at runtime, but this seems overkill for what I need.

fallen

Pharan

The best solution depends on your setup.
Modifying the original attachment will cause any changes to it to become applied to all other skeletons using that attachment. If you don't want that, making a new copy of the attachment is a good way to go. But making a copy means animations won't be able to key the new attachment you make, unless you make a new skin and put that attachment in that skin.

After you've decided that, you can just mimic what AtlasAttachmentLoader and SkeletonJson does when an attachment is loaded.

https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-c/src/spine/SkeletonJson.c#L865
https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-c/src/spine/AtlasAttachmentLoader.c

Note that for linked meshes, you'll want to do it after everything has loaded. Linked meshes load in two steps and you can't copy its properties in the middle because its pointers and values aren't assigned until the loader finds its parent mesh.

fallen

@Pharan - thanks for the thoughtful reply and pointing at the code samples.

Following your advice I have decided that I want to modify the original Skeleton, and am just changing the attachments directly. I have had success with a standard Region Attachment, but am hitting a snag with my Linked Meshes.

EDIT: I eventually figured this out, currently my linked meshes are actually Weighted Meshes, as they have binding to bones and weights. I read elsewhere on the forum that as of 3.3 these will all just be Linked Meshes, but for now

this was fixed by using the right class!

This is all being done after the full skeleton load

          myAtlas = Atlas_createFromFile(atlasDataFile, 0);
SkeletonJson* json = SkeletonJson_create(myAtlastlas);
json->scale = 1;
skeletonData = SkeletonJson_readSkeletonDataFile(json, skeletonDataFile);
CCAssert(skeletonData, json->error ? json->error : "Error reading skeleton data file.");
SkeletonJson_dispose(json);
          mSpine->setSkin("Spacer3");

Here is the code being used for the Region Attachment

               {
         // Hand is a standard REGION ATTACHMENT      

      // HAND!
                     // try modifying the render objects directly:
                     spAtlasRegion* region = spAtlas_findRegion(myAtlas, "crew_hand_right");
                     if (!region) {
                        assert("Region not found!!");
                        return 0;
                     }
                     // find a slot with a standard texture under a skin attachment
                     spSlot* rHand = mSpine->findSlot("Arm - Right - Hand");
                     spRegionAttachment* regionAttachment = (spRegionAttachment*)rHand->attachment;
                     // help :)
                     spRegionAttachment_setUVs(regionAttachment, region->u, region->v, region->u2, region->v2, region->rotate);
                     regionAttachment->regionOffsetX = region->offsetX;
                     regionAttachment->regionOffsetY = region->offsetY;
                     regionAttachment->regionWidth = region->width;
                     regionAttachment->regionHeight = region->height;
                     regionAttachment->regionOriginalWidth = region->originalWidth;
                     regionAttachment->regionOriginalHeight = region->originalHeight;
                     

              }   
mSpine->setSlotsToSetupPose();

Here is the code for the weighted linked mesh:

                  { 
                     // LEGS!
// legs are a LINKED MESH
                     // try modifying the render objects directly:
                     spAtlasRegion* region = spAtlas_findRegion(myAtlas, "crew_legs");
                     if (!region) {
                        assert("Region not found!!");
                        return 0;
                     }
                  

                 // find a slot with a linked mesh under a skin attachment
                 spSlot* legs = mSpine->findSlot("Legs");
                 spMeshAttachment* meshAttachment = (spMeshAttachment*)legs->attachment;
                 // help :)
                 meshAttachment->rendererObject = region;
                 meshAttachment->regionU = region->u;
                 meshAttachment->regionV = region->v;
                 meshAttachment->regionU2 = region->u2;
                 meshAttachment->regionV2 = region->v2;
                 meshAttachment->regionRotate = region->rotate;
                 meshAttachment->regionOffsetX = region->offsetX;
                 meshAttachment->regionOffsetY = region->offsetY;
                 meshAttachment->regionWidth = region->width;
                 meshAttachment->regionHeight = region->height;
                 meshAttachment->regionOriginalWidth = region->originalWidth;
                 meshAttachment->regionOriginalHeight = region->originalHeight;

  // 2. ReadAttachment. case: LinkedMesh (SkeletonJson.cs)
  meshAttachment->r = 1.0f;
  meshAttachment->g = 1.0f;
  meshAttachment->b = 1.0f;
  meshAttachment->a = 1.0f;
  // 3. Link mesh with parent. (SkeletonJson.cs)
  meshAttachment->inheritFFD = true; 
  spWeightedMeshAttachment_updateUVs(meshAttachment);
              }
mSpine->setSlotsToSetupPose();

Hope this helps those who many follow in my footsteps. Great day, LOVE SPINE.. I think I will now be able to avoid creating 200 skins lol

Ok, while this is working, it is grating against our caching of Spine objects. As you mentioned, @Pharan, changing the attachment on the skin changes it for all shared Spines. I am now working on the code to duplicate skins (using other forum posts) and will post my code here when I get it worked out.

Pharan

When making skins, you can make "throwaway" ones that you don't add to skeletonData (and are then not accessible to other instances through skeletonData).
If you have multiple instances of the same skeleton, it may be useful to have one duplicate of the original skin per skeleton, and keep your pointer to it yourself.
The more optimized way to do it may be to lazy-instantiate a new skin only when something changes. But skins are pretty light on memory so there's probably no reason to do it like that

fallen

@Pharan - we'd love to have a single instance of the Skeleton. I got it working above by just modifying the renderObjects on the attachments / meshes, but as you had warned it affects all spines using the Skeleton. Therefore, we had to turn off our skeleton object caching and create 8 skeletons instead of one, which was definitely a performance hit.

So, now I am working on your suggestion to create new / throw away skins. I am pretty stuck, and appreciate any help you can give.

EDIT: Working on isolating where I have the actual problem, and will post a clearer question.

Pharan

I don't think there's a need to turn off the caching. You just need to use a unique skin for each instance, and reset everything properly.

What in particular has you stuck?
As far as I can tell, a Skin in spine-c is a linked list of skin entries. Each entry defines "key name" and attachment object.
You duplicate a skin by duplicating all the nodes.
Then you call setSkin on your new skin duplicate.

I'll point @badlogic over here for syntax and structure help. He knows spine-c better than I do.

fallen

@Pharan and @badlogic - thanks in advance for the help.

I believe that I am now copying the skin correctly, simply by iterating the slots list and adding the original attchment to a new skin.

{
// creates a skeleton animation from file or cached skeleton object
spine::SkeletonAnimation* skel = makeSkeletonAnimation("sprites/st2_grayman.json", "sprites/st2_grayman.txt");
// start the new skin
string skinName = "New Skin";
spSkin* skin = spSkin_create(skinName.c_str());
CCLOG("[SPINE TEST] Started skin %s", skinName.c_str());
copySkin(skel, skin); 
// 1b. change the spine to use this new skin
spSkeleton_setSkin(skel->skeleton, skin);
skel->setSkin(skinName.c_str());
}

// this function copies a hardcoded skin ("Starter Skin") to a new skin
void STCombatCrew::copySkin(spine::SkeletonAnimation* mSpine, spSkin* skin) {   

   // this is the skin we always copy:
   spSkin* oldSkin = spSkeletonData_findSkin(mSpine->skeleton->data, "Starter Skin");
    // Loop through every slot
   for (int i = 0; i < mSpine->skeleton->slotsCount; ++i) {
        // Get the slot index
        int slotIndex = spSkeleton_findSlotIndex(mSpine->skeleton, mSpine->skeleton->data->slots[i]->name);
        // Get attachments and names from this slot
      spSlot* slot = mSpine->skeleton->slots[i];
// if there is an attachment, then copy
      if(slot->attachment != NULL) {
         Skin_addAttachment(skin, slotIndex, slot->data->name, slot->attachment);
         CCLOG("[Spine Test] at index %d with slot name %s attchment for %s added to Skin.", slotIndex, slot->data->name, slot->attachment->name);
      } else {
         CCLOG("[Spine Test] skipped %d with slot name %s", slotIndex, slot->data->name);
      }
      // attach);
   }
}

It seems this is working, I am able to create a new skin and display the spine in the new skin. It looks like the original.

I am concerned I may not be copying all attachments (if a slot has multiple skin placeholders and attachments). Also, I have found that if the name of the Slot ("Torso") does not match the name of the Skin Placeholder ("Skin - Torso") that the attachment does not end up getting copied. Not yet sure why.

Now that I have this mostly working, I've started to write code to update the attachments in New Skin by copying the old one, but I am finding that all skins are effected.

Any suggestions on how to fix / improve the code above so the first step is really working?

Thanks!

Pharan

Given it's a linked list, this would be how to copy an spSkin in spine-c. (Broadly speaking. I'm not sure of the syntax.)

spSkin* oldSkin = spSkeletonData_findSkin(mSpine->skeleton->data, "Starter Skin");
string skinName = "New Skin";
spSkin* newSkin = spSkin_create(skinName.c_str());

const _Entry* entry = ((_spSkin*)oldSkin)->entries; // <

---

 need cast to get "private" member "entries". not quite sure of the syntax here. is const correct?? maybe not needed?
while (entry) {
     Skin_addAttachment(newSkin , entry->slotIndex, entry->name, entry->attachment); //attachment object will be shared with the old skin unless you also duplicate the attachment.
     entry = entry->next;
}

// add stuff. or change stuff? Maybe change stuff in the middle of duplicating.

Mario

You definitely want to iterate all attachments like Pharan illustrated a shallow copy via Skin_addAttachment.

If you modify a shallowly copied attachment in your new skin, it will affect the skins sharing that attachment. You will have to make deep copies of the attachments you add to the new skin. We currently don't have the equivalent of copy constructors in the API. If we added those, we'd have to come up with an easily manageable ownership model for memory management.

Nate

SkeletonData owns the skins and attachments loaded from JSON. Probably makes sense that any skins and attachments you allocate (copies or otherwise) you would be responsible for freeing.

Pharan

You know, I was checking the PRs and I completely forgot about this: https://github.com/EsotericSoftware/spine-runtimes/pull/465/commits/c7df6d1168c8b2e1140f4997ddd1cd2e7829c51c

Someone needed something similar and added the missing functionality.
Looks like Spine 2.1 though.

At least on the skin side, it might work.
Attachment cloning needs updating.

fallen

@Pharan, @Nate, @badlogic - thanks for the help! Especially the code from the pull 465 has been very helpful. I have now been able to clone a skin with shallow copies. That seems to work very well.

I have moved on to the code for cloning region attachments (starting simple). This does a deep copy, using the example from the pull 465 as well. I then add the newly cloned attachment to the skin, and set the attachment for the slot on the spine.

Everything seems to work, and my logs that get the attachment from the skin seem to indicate that the new attachment is in place, however the visual result in the game is not altered.

// generic function to clone an attachment, switch its region, and then set it as the attachment for a given slot
void cloneAndUpdateAttachment(spine::SkeletonAnimation* mSpine, spSkin* skin, string slotName, string attachmentName, string newRegion) {
// find the slot
   int slotIndex = spSkeleton_findSlotIndex(mSpine->skeleton, slotName.c_str());
// find the attachment we plan to clone
   spAttachment* attachment = spSkin_getAttachment(skin, slotIndex, slotName.c_str());
   if(attachment != NULL) {
      switch(attachment->type) {
         case SP_ATTACHMENT_MESH:
         case SP_ATTACHMENT_LINKED_MESH:
         case SP_ATTACHMENT_WEIGHTED_MESH:
         case SP_ATTACHMENT_WEIGHTED_LINKED_MESH:{
            // This is a WEIGHTED MESH: so extra work to be done here
            spAtlasRegion* region = spAtlas_findRegion(this->getRegionMap()->findAtlas("sprites/st2_grayman.txt"), newRegion.c_str());
            if (!region) {
               assert("[Combat Spine] Update standard Linked Mesh: region %s not found.", newRegion.c_str());
               return;
            }
// TODO: haven't implemented meshes yet, want to get region attachments working
            break;
         }
         case SP_ATTACHMENT_REGION: {
// finding the new region (in the case of the Torso, "merchant_torso" from the atlast
            spAtlasRegion* region = spAtlas_findRegion(this->getRegionMap()->findAtlas("sprites/st2_grayman.txt"), newRegion.c_str());
            if (!region) {
               assert("[Combat Spine] Update standard Linked Mesh: region %s not found.", newRegion.c_str());
               return;
            }

// start the deep clone process
            const spRegionAttachment* const self = SUB_CAST(spRegionAttachment, attachment);
// name the new attachment after the new region (in the case of the Torso slot, "merchant_torso"
            spRegionAttachment* const result = spRegionAttachment_create(newRegion.c_str());
            MALLOC_STR(result->path, newRegion.c_str());
            result->x = self->x;
            result->y = self->y;
            result->scaleX = self->scaleX;
            result->scaleY = self->scaleY;
            result->rotation = self->rotation;
            result->width = self->width;
            result->height = self->height;
            result->r = self->r;
            result->g = self->g;
            result->b = self->b;
            result->a = self->a;
// here, I am pointing the new attachment at the new region, merchant_torso
            result->rendererObject = region;
            spRegionAttachment_setUVs(result, region->u, region->v, region->u2, region->v2, region->rotate);

// rebuild the region data
            result->regionOffsetX = region->offsetX;
            result->regionOffsetY = region->offsetY;
            result->regionWidth = region->width;
            result->regionHeight = region->height;
            result->regionOriginalWidth = region->originalWidth;
            result->regionOriginalHeight = region->originalHeight;
// memcopy some values - copied from pull 465
            memcpy( result->offset, self->offset, sizeof( result->offset ) );
            memcpy( result->uvs, self->uvs, sizeof( result->offset ) );

// testing a specific slot 

---

 this is the slot name "Torso"  at this point, the attachment name is "crew_torso"
            if(slotIndex == 3) {
               spAttachment* attDone = spSkin_getAttachment(skin, slotIndex, slotName.c_str());
               CCLOG("At start of Clone, attachment is %s", attDone->name);
            }            

// add the attachment to the skin under the slot index and name
            Skin_addAttachment(skin, slotIndex, slotName.c_str(), SUPER_CAST(spAttachment, result));
// tell the current spine::SkeletonAnimation to use the newest attachment
            bool set = mSpine->setAttachment(slotName.c_str(), newRegion.c_str());

// testing a specific slot 

---

 this is the slot name "Torso"  at this point, the attachment name is "merchant_torso"
            if(slotIndex == 3) {
               spAttachment* attDone = spSkin_getAttachment(skin, slotIndex, slotName.c_str());
               CCLOG("At end of Clone, attachment is %s", attDone->name);
            }
            

        }
        break;
     }
  }
   }

The log output for the Torso slot is:

At start of Clone, attachment is crew_torso
At end of Clone, attachment is merchant_torso

So, as far as I can tell, I have successfully added the attachment and even set it for that skin. However, the Spine is not visually different.

Any help is highly appreciated, I've been banging my head against this for days now.

Pharan

Where's the part where the skeleton's skin is set?

mSpine->setAttachment uses the skin currently set on the skeleton object.
If the currently set skin wasn't the skin that you modified, no changes would show up, I suppose.

I also think, the way skins are set up in spine-c, that you need to remove the old entry before calling Skin_addAttachment. 'cause it finds the first match (which was the original one). Calling addAttachment before removing the original causes the skin to have two skin entries for the same key, and the first match is the one that's used.

This is not true in the other runtimes.

fallen

The skin is being set before the clone-and-update:

string skinName = "NewSkin";
// 1a. create a new skin
spSkin* skin = spSkin_create(skinName.c_str());
// 1b. copies the skin by iterating _Entry list
copySkin(skel, skin); 
// 1b. change the spine to use this new skin
skel->setSkin(skinName.c_str());
// clone and update the attachment:
cloneAndUpdateAttachment(skel, skin, "Torso", "crew_torso", "merchant_torso");

Pharan wrote
I also think, the way skins are set up in spine-c, that you need to remove the old entry before calling Skin_addAttachment. 'cause it finds the first match (which was the original one). Calling addAttachment before removing the original causes the skin to have two skin entries for the same key, and the first match is the one that's used.

This is not true in the other runtimes.

This is very likely the clue I was looking for. I have been iterating the _Entry list and am seeing 2 attachments on that slot, both the old one and the new one. Which would make sense that the old one is still getting pulled.

Any advice on how to delete an entry? Should I do it manually in the linked list?

// my logging, format "entry->slotIndex) entry->name with path entry->attachment->path"
// occurs once
[SKIN READER] 3) Torso with path merchant_torso
[SKIN READER] 5) Arm - Left - Hand with path hand_left
...
[SKIN READER] 6) Pistol with path pistol
// occurs twice!
[SKIN READER] 3) Torso with path crew_torso

Pharan

Remember that it's a linked list. Linked lists are strung together with pointers.
To delete an entry in the middle, you have to point the previous entry to the next one, instead of the one you deleted. (Also, I think bad things happen when you dereference freed memory in C?)

I guess the other option too is just to search for and change the original entry instead of deleting it and adding a new one. The algorithm for the searching part should be in the getAttachment method. You can make a new method similar to it that returns the entry instead of returning just the attachment. Then modify that entry.

fallen

@phahan - huge thanks for sticking with me on this.

Just doing a ret-con on my post here, as I've been putting breakpoints in SkeletonRenderer::draw() to try to track down why the new attachment isn't showing. Turns out I was failing to set the skin properly.

Now ...

spSkeleton_setSkin(skel->skeleton, skin);

And

at least progress. Instead of the original Torso image, it is now showing nothing.

Yea for something to hunt down and fix!

@Pharan - just an update, it is working. Thank you for all your support

we loved backing your KickStarter, we're dedicated customers, and we love working with your team. You made my day with this one.

The final fix was to get the order of the setSkin functions right ...

string skinName = "NewSkin";
// 1a. create a new skin
spSkin* skin = spSkin_create(skinName.c_str());
// 1b. copies the skin by iterating _Entry list
copySkin(skel, skin);  // this now includes the changes to the _Entry linked list as they are added
// 1c. add the skin to the skeleton
spSkeleton_setSkin(skel->skeleton, skin);
// 1d. change the spine to use this newly added skin
skel->setSkin(skinName.c_str());

Nate wrote
SkeletonData owns the skins and attachments loaded from JSON. Probably makes sense that any skins and attachments you allocate (copies or otherwise) you would be responsible for freeing.

@Nate & @Pharan - you've both been more than helpful with this! We've got a fully working solution now and we're dropping in art and headed toward the goal of about 500 dynamic skins that could be created at runtime. We are doing our own memory management on our skins and attachments, and that is going well, no leaks there.

However, once we get these Spines into animations, we start having leaks. We are having a set of memory leaks around spTimeline objects (curve, base).

Below you can see the call stack from our Visual Leak Detector output, showing how the leak is related to the allocation of a spCurveTimeline

The root of thise stack in our code is:

skeletonData = SkeletonJson_readSkeletonDataFile(json, skeletonDataFile);
CCAssert(skeletonData, json->error ? json->error : "Error reading skeleton data file.");
SkeletonJson_dispose(json);

And later, we are disposing of this skeletonData we've been caching:

SkeletonData_dispose(d);

Any advice would be appreciated on how to figure out where we are failing to clean-up objects. I believe I remember having seen it mentioned that if you were building your own skin's dynamically, there might be work to do related to animation frames, but I haven't been able to find that reference when searching again.

VLD Output:

f:\dd\vctools\crt_bld\self_x86\crt\src\dbgmalloc.c (55): MSVCR110D.dll!malloc
c:\cocos2dx-2.2\extensions\spine\extension.cpp (43): StarTraders2.exe!_malloc + 0xC bytes
c:\cocos2dx-2.2\extensions\spine\extension.cpp (46): StarTraders2.exe!_calloc + 0x15 bytes
c:\cocos2dx-2.2\extensions\spine\animation.cpp (121): StarTraders2.exe!_spCurveTimeline_init + 0x1F bytes
c:\cocos2dx-2.2\extensions\spine\animation.cpp (244): StarTraders2.exe!_spBaseTimeline_create + 0x1A bytes
c:\cocos2dx-2.2\extensions\spine\animation.cpp (404): StarTraders2.exe!spScaleTimeline_create + 0x12 bytes
c:\cocos2dx-2.2\extensions\spine\skeletonjson.cpp (244): StarTraders2.exe!_spSkeletonJson_readAnimation + 0x18 bytes
c:\cocos2dx-2.2\extensions\spine\skeletonjson.cpp (899): StarTraders2.exe!spSkeletonJson_readSkeletonData + 0x14 bytes
c:\cocos2dx-2.2\extensions\spine\skeletonjson.cpp (436): StarTraders2.exe!spSkeletonJson_readSkeletonDataFile + 0xD bytes
c:\cocos2dx-2.2\startraders2\classes\stregionmapscene.cpp (743): StarTraders2.exe!STRegionMapScene::makeSkeletonAnimation + 0xD bytes

Mario

Hrm, it appears that the timelines in the loaded animation isn't disposed correctly. Could you provide me with a minimal C(++) reproduction case for this?

fallen

badlogic wrote
Hrm, it appears that the timelines in the loaded animation isn't disposed correctly. Could you provide me with a minimal C(++) reproduction case for this?

I can work on that. Let me ask though

your response seems to indicate that this might be a bug in Spine (C++) without dynamically creating skins? If that is the case, I can do some more investigation into our animations and see if we can make it happen without the dynamic skins overhead. Giving you a "minimum reproduction case" with the dynamic skins stuff is still going to be pretty weighty.

Mario

To be honest, I'm not sure I can rule out a bug in spine-c. Hard to tell from the limited information in your previous post. I'm happy with whatever you can throw at me!

다음 페이지 »