Mix n Match across scenes

chrisoshea

I've got a game where your player is customisable with lots of parts, but you can only customise them in certain levels/scenes.

So my idea was to create a persistent player prefab that would exist across all scenes. That way I don't have to create the attachments, skins, repack every time you load a new scene. However this is causing me some issues.

So what i've started to do instead is have a manager class, don't destroy on load, with a spine prefab inside. This will exist and be accessible across all scenes. The customisation is done on this prefab. Then in each scene, they request a copy of that prefab and that copy is the game object the player controller moves around in each scene.

However when I do the customisation and repack the texture on the source gameobject, when I instantiate a new copy it doesn't carry over the new attachments and repacked texture/material.

Is that expected behaviour and do you have any suggestions?

Thanks

Harald

chrisoshea The above code is basically correct (as it mirrors the example code). The missing part which is not shown here, which likely contains the actual issue, is how you add your skin parts to the customSkin.

chrisoshea So my idea was to create a persistent player prefab that would exist across all scenes.

I'm not sure you mean a literal Unity prefab asset, which does not get modified at runtime after the game is built. Do you mean something else by "persistent prefab"?

Spinebot

That is expected behaviour, yes. When you instantiate a copy of the prefab, the new instance gets a fresh SkeletonAnimation (or SkeletonGraphic) component, which reinitialises its skeleton from the original SkeletonDataAsset. Because the repacked skin and its generated texture/material are created at runtime and only live on the original instance's skeleton, they are not part of the asset and therefore don't carry over to the new instance automatically.

Here are a few approaches to solve this:

Store the repacked skin and material on your manager, then apply them to each new instance

After you do your customisation and repack on the source object, save references to the resulting Skin, Material, and Texture on your manager class. Then, whenever you instantiate a new copy, apply those stored values to the new instance's skeleton right after instantiation.

// On your manager, after repacking:
Skin repackedSkin = runtimeSkin.GetRepackedSkin("Repacked skin", materialTemplate, out runtimeMaterial, out runtimeAtlas);
skeleton.SetSkin(repackedSkin);
skeleton.SetSlotsToSetupPose();

// Store these references
storedSkin = repackedSkin;
storedMaterial = runtimeMaterial;
storedTexture = runtimeAtlas;

Then when a new scene instantiates a copy:

// On the new instance's SkeletonAnimation:
var skeleton = newInstance.GetComponent<SkeletonAnimation>().Skeleton;
skeleton.SetSkin(manager.storedSkin);
skeleton.SetSlotsToSetupPose();
newInstance.GetComponent<SkeletonAnimation>().GetComponent<MeshRenderer>().material = manager.storedMaterial;

Use the source object directly instead of instantiating a copy

Rather than copying the prefab each scene, you can simply move or reposition the existing persistent source object within each scene, since it already has the correct skin applied. This sidesteps the problem entirely.

Rebuild the skin on each new instance from the stored skin choices

Instead of storing the repacked result, store the list of skin names the player chose (e.g. "hair/brown", "clothes/hoodie-orange", etc.) on your manager. Then after instantiating a new copy, rebuild and repack the skin from scratch using those choices:

Skin runtimeSkin = new Skin("runtime skin");
runtimeSkin.AddSkin(skeletonData.FindSkin("skin-base"));
runtimeSkin.AddSkin(skeletonData.FindSkin(manager.chosenHair));
runtimeSkin.AddSkin(skeletonData.FindSkin(manager.chosenClothes));
// etc.

Skin repackedSkin = runtimeSkin.GetRepackedSkin("Repacked skin", materialTemplate, out runtimeMaterial, out runtimeAtlas);
skeleton.SetSkin(repackedSkin);
skeleton.SetSlotsToSetupPose();

This is slightly more work per scene load, but keeps things clean and avoids holding onto runtime textures longer than necessary. Remember to call AtlasUtilities.ClearCache() after repacking if you won't be doing more repack operations immediately:

using Spine.Unity.AttachmentTools;
AtlasUtilities.ClearCache();

For more detail on the repacking workflow, see the spine-unity Mix and Match documentation and the Spine Examples/Other Examples/Mix and Match example scene and MixAndMatch.cs script included with the spine-unity package.

chrisoshea

My repacked skin currently looks like this (based on the attachment version of mix n match):

repackingOutput.DestroyGeneratedAssets();
var settings = AtlasUtilities.RepackAttachmentsSettings.Default;
settings.UseSourceMaterialsFrom(skeletonAnimation.SkeletonDataAsset);
settings.maxAtlasSize = 1024;
Skin repackedSkin = customSkin.GetRepackedSkin(repackedSkinName, settings, ref repackingOutput);

with this defined at the top
private AtlasUtilities.RepackAttachmentsOutput repackingOutput;

chrisoshea

So the script on my spine object, during Start I create a skin:
customSkin = new Skin(customSkinName);

Then when you pick a body part in the customiser it finds the right named attachment and does:

// find the right attachment
            Attachment templateAttachment = templateSkin.GetAttachment(slotIndex, attachmentName);

 if (templateAttachment == null)
            {
                Debug.LogError("Could not find attachment " + attachmentName + " slotIndex=" + slotIndex);
                return;
            }

            // make a copy of that attachment
            Attachment attachment = templateAttachment.Copy();

            attachment.SetRegion(sprite, sourceMaterial, premultiplyAlpha: true, true);

            Debug.Log("slotdata=" + slotData + " index=" + slotIndex + " attach=" + attachment.Name);

            customSkin.SetAttachment(slotIndex, attachmentName, attachment);
            
            RefreshSkeletonAttachments();

So that gets called for each body part (well slot change).

private void RefreshSkeletonAttachments()
        {
            // apply the custom skin
            skeleton.SetSkin(customSkin);
            
            skeletonAnimation.Skeleton.SetupPoseSlots();
            skeletonAnimation.AnimationState.Apply(skeletonAnimation.Skeleton);
        }

then when finished:

public void OptimizeSpineModel()
        {
            // Create a repacked skin.
            // Note: materials and textures returned by previous GetRepackedSkin() calls behave like 'new Texture2D()'
            // and need to be destroyed.
            repackingOutput.DestroyGeneratedAssets();
            var settings = AtlasUtilities.RepackAttachmentsSettings.Default;
            settings.UseSourceMaterialsFrom(skeletonAnimation.SkeletonDataAsset);
            settings.maxAtlasSize = 1024;
            Skin repackedSkin = customSkin.GetRepackedSkin(repackedSkinName, settings, ref repackingOutput);

            // clear the skin
            customSkin.Clear();

            //  clear the textures cache
            AtlasUtilities.ClearCache();
            Resources.UnloadUnusedAssets();

            // Use the repacked skin.
            skeletonAnimation.Skeleton.Skin = repackedSkin;

            RefreshSkeletonAttachments();
            
        }

Although I've just realised at the end of Optimize I'm calling refresh, which is setting the sky to customSkin, but it should be the repackedSkin right? Weirdly it seems to work though as I can see the texture on the character change.

Harald

chrisoshea Although I've just realised at the end of Optimize I'm calling refresh, which is setting the sky to customSkin, but it should be the repackedSkin right?

If I read your code correctly, then you are first calling customSkin.Clear() and then RefreshSkeletonAttachments() calls skeleton.SetSkin(customSkin) so effectively assigning the cleared skin.

chrisoshea

Please ignore the code with the skin assigment, I pasted broken code.

So i was doing what the bot suggests: "Use the source object directly instead of instantiating a copy"
but I had issues with making sure the object was unparented, hidden and restored, making sure it was kept inside the object that wasnt destroyed before the scene changed.

"Rebuild the skin on each new instance from the stored skin choices"
This would be the easiest way, you could just drop the player in any scene. However I thought making the skin, applying it then optimising the skin every time you change scenes might be a performance overhead not worth it? Would be better to have one player that could be reused without doing the custom skin each scene.

So this is what I'm trying now: "Store the repacked skin and material on your manager, then apply them to each new instance"

current code:

            Skin repackedSkin = customSkin.GetRepackedSkin(repackedSkinName, settings, ref repackingOutput);

            // store this for later
            repackedTexture = repackingOutput.outputTexture;
            repackedMaterial = repackingOutput.outputMaterial;

SO I just reapply the stored texture and material to every cloned Spine object?

Harald

chrisoshea So i was doing what the bot suggests: "Use the source object directly instead of instantiating a copy"
but I had issues with making sure the object was unparented, hidden and restored, making sure it was kept inside the object that wasnt destroyed before the scene changed.

I'm sorry to say, but if you are having troubles ensuring that the preferred solution works as intended, I would still recommend investing some more time debugging it and making it work. The problems stated above sound more like issues with your scene management, rather than problems with the spine-unity runtime. You basically should just have to briefly let the player's top GameObject be parented at the scene root (having no parent), and then calling DontDestroyOnLoad(gameObject); in Awake once.

void Awake() {
    transform.SetParent(null); // must be a root object
    DontDestroyOnLoad(gameObject);
}

chrisoshea "Rebuild the skin on each new instance from the stored skin choices"
This would be the easiest way, you could just drop the player in any scene. However I thought making the skin, applying it then optimising the skin every time you change scenes might be a performance overhead not worth it? Would be better to have one player that could be reused without doing the custom skin each scene.

Repacking would only be necessary if you change the skin to a differently composed one.

chrisoshea

Rather than one player prefab (with Spine attached) that stays across all scenes, imagine I have this prefab in every scene (which helps with layout etc). I don't want to do anything expensive each scene change, so what is the most expensive thing? Optimizing the texture?

If I had a player prefab in each scene, then a singleton that exists across all scenes that sets the visual look of this prefab. What would I need to store on the singleton and change on each player. I.e. do I still need to create a custom skin by adding attachments and apply per scene? or could i just store a reference to the material and texture and apply that on each scene load? or would i also need to change slots etc? Thats the part I'm slightly confused by. Thanks

Harald

chrisoshea I don't want to do anything expensive each scene change, so what is the most expensive thing? Optimizing the texture?

The texture repacking operation, yes. You likely won't notice a single texture repacking operation alongside scene loading thought.

chrisoshea What would I need to store on the singleton and change on each player. I.e. do I still need to create a custom skin by adding attachments and apply per scene? or could i just store a reference to the material and texture and apply that on each scene load? or would i also need to change slots etc?

You need to have your skeleton state (skins, attachments at slots) in sync with the materials, because the materials are assigned based on the currently active attachments (the content of the skin) which hold references to the required atlas regions and materials. You can't let the skeleton state be the default skin and just assign a repacked texture, this will be reset as soon as next frame the SkeletonRenderer updates the active materials according to the currently needed ones based on the visible attachments at the slots.

See the documentation here:
https://esotericsoftware.com/spine-unity-rendering#Rendering