• RuntimesUnity

  • How to properly attach sprites with SkeletonPartsRenderer

To achieve the setup you described with Spine Unity, you can consider the following approach to streamline your workflow and avoid cumbersome workarounds:

  1. Use Skins for Equipment: Instead of creating attachments on the fly, consider using skins to manage different equipment like helmets and cloaks. Skins allow you to organize attachments and switch them easily at runtime. You can create a skin for each piece of equipment and apply it when needed.

  2. SkeletonPartsRenderer and Draw Order: The SkeletonPartsRenderer is useful for separating parts of your skeleton for different rendering needs. However, managing draw order and visibility can become complex. Instead of manually adjusting sorting orders, you can use Spine's built-in draw order functionality to manage which slots are rendered on top. This can be controlled through animations or by setting the draw order programmatically.

  3. Visibility Management: For managing visibility, instead of setting alpha to zero, you can use Spine's attachment visibility features. You can set attachments to null to hide them or use a placeholder attachment that is invisible. This avoids issues with submesh instructions being affected by alpha values.

  4. Dynamic Attachment Management: If you need to dynamically add or remove attachments, ensure that your code handles the creation and destruction of attachments efficiently. You can cache attachments and reuse them instead of creating new ones each time.

  5. Optimize Renderer Usage: If certain parts of your character (like cloaks) require special rendering, consider using separate renderers only when necessary. You can enable or disable these renderers based on the current equipment state to optimize performance.

By organizing your equipment using skins and leveraging Spine's built-in features for draw order and visibility, you can simplify your setup and reduce the need for complex workarounds. This approach should provide a more maintainable and efficient workflow for managing character equipment in Spine Unity.

Related Discussions
...

Keydus Your description is detailed, but we would still prefer to see the actual project to more accurately confirm what you are trying to do and what you are having trouble with, rather than just guessing from the text. So if you don't mind, could you create a minimal Unity project that confirms your problem and email it to us?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

      Keydus I have successfully opened your Unity project and our Unity expert Harald will review and advise you later.

        @Keydus Thanks for sending the reproduction project. Unfortunately it was not a minimal Unity project which shows only the few relevant lines of code which trigger your issue but whole gameplay classed SpineRendererSeparatorSortingOrder, PlayerEquipService and UpdateEquipmentAttachmentAnimation which contain far too much logic for us to efficiently check.

        From the images and the desired outcome I think you are in the following situation:
        1) Your skeleton has varying draw order due to front and back view.
        2) You want to insert (interleave) two items between certain slots.

        What you need to do:

        • 1) Prepare the insertion-slots in your skeleton where the separation shall always happen.
        • 2) Either:
          • a) Ensure that the number of separated parts is always the same (3 with 2 splits). Then the hat GameObject item shall be at sibling index 2, the cloak at sibling index 4. When changing from front to back exchange the sibling index of the two items, cloak at sibling index 2 and hat at sibling index 4. Keep references to the two inserted GameObjects, then changing sibling index should be trivial.
          • b) If animations dictate your draw and split order randomly, you could set one or multiple events at each animation when the draw order changes so that the split is somewhere else. E.g. raise events string: "hat", int: "2" and an event string: "cloak", int: "4" or raise a packed event string: "parts", int:"2", float: "4" to pack more information into one event if you would like to save resources.

          Harald

          Hello! Thanks for looking at the project. Unfortunately it was hard to make a very minimal reproducible code as there are multiple things involved here such as creating attachments dynamically.

          Here is the global topo :

          • Having an animated character with 2 views (F and B) controlled by animations
          • Having two slots (F and B) for the hat without any attachment
          • Having two slots (F and B) for the cloak with a MeshAttachment to allow movements on sprites dynamically
          • Wanting to have the possibility to tell a priority in the sorting order using SkeletonRendererSeparator (as stated here : https://fr.esotericsoftware.com/spine-unity-utility-components#SkeletonRenderSeparator)
          • Needed attachments should be created dynamically
          • Attachments should be hidden/removed (since the cloak have an attachment and the hat do not, I feel that's it a mix of the two) when the animation change
          • SkeletonPartsRenderer should be created dynamically and same for the Separator Slots as well

          I hope it makes it more clear. The need for creating such things dynamically is that we are going to create multiple more characters and I don't want to handle it during import from Spine to Unity. I prefer to do it dynamically and only when needed

          I would like to have more precisions on your suggested approach :

          1) Prepare the insertion-slots in your skeleton where the separation shall always happen.

          You mean that it should be prepared on the skeleton prefab directly instead of inside the code, right? I tried both approach and AFAIK it does not change anything.

          Ensure that the number of separated parts is always the same (3 with 2 splits)
          If I understand correctly, by 3 with 2 splits you mean 🇦

          • 0 is the skeleton
          • 1 is an attachment (hat or cloak depending on DrawOrder & cie)
          • 2 is another attachment (hat or cloak depending on DrawOrder & cie)

          Currently, I have 5 separated parts as I create one part per view (F, B) and per equipment slot (hat, cloak). Could easily reduce to only one per equipment slot instead.

          a) Ensure that the number of separated parts is always the same (3 with 2 splits). Then the hat GameObject item shall be at sibling index 2, the cloak at sibling index 4. When changing from front to back exchange the sibling index of the two items, cloak at sibling index 2 and hat at sibling index 4. Keep references to the two inserted GameObjects, then changing sibling index should be trivial.

          In this whole part I don't think I'm completely following what you said about the sibling index. What should I do with them? The main problem, for me, is that I cannot know which slot (hat or cloak) will be rendered in which PartRenderer (I looked through the MeshGenerator class where instructions are built EsotericSoftware/spine-runtimesblob/4.2/spine-unity/Assets/Spine/Runtime/spine-unity/Mesh%20Generation/MeshGenerator.cs#L369

          I initially looked through the code and deducted that it was on the DrawOrder but then realized that some other things had impact too such as the alpha of the slot that will skip instructions
          EsotericSoftware/spine-runtimesblob/4.2/spine-unity/Assets/Spine/Runtime/spine-unity/Mesh%20Generation/MeshGenerator.cs#L236
          which completely alters the order of the PartsRenderer

          b) If animations dictate your draw and split order randomly, you could set one or multiple events at each animation when the draw order changes so that the split is somewhere else.

          And this is where it becomes a bit more complex because as I stated before the DrawOrder is not the only responsible to make this split.

          I might have a solution to dynamically change the sorting order of the PartsRenderer on the animation change to apply the one calculated from the visibility (should be rendered first or last) but still I can't know which attachment/slot is rendered in which PartsRenderer

          Thanks for helping though!

              Keydus Unfortunately it was hard to make a very minimal reproducible code as there are multiple things involved here such as creating attachments dynamically.

              If multiple things are involved, your code should include multiple lines of code and multiple asset references, not multiple classes of which only parts are used.

              We know that it may take some effort to reduce your code down to the required parts. Please note however that you can do that much better than we would be able to, as you understand what is necessary while we do not. Please understand that we don't have the time and resources to step through your code and see which parts are actually relevant.

              Keydus Having an animated character with 2 views (F and B) controlled by animations
              Having two slots (F and B) for the hat without any attachment

              I previously assumed that you have only one shared item-insertion (separation) slot for both the back and front view versions. Things are more complicated if you have two slots for each item, one per view. Is there a reason why you need separate separation-slots for front and back view? You should be able to have a single separation slot and move it around in the draw-order of your animations to where the respective external GameObject item shall be inserted.

              Having looked at your Unity project again, I noticed that your inserted item sprites are not actually Sprite GameObjects but skeleton attachments. Why do you want to separate those into split GameObject parts with SkeletonRenderSeparator? SkeletonRenderSeparator is for splitting a skeleton into e.g. 2 parts so that you can interleave other GameObjects in-between them. Could you explain the motivation for using SkeletonRenderSeparator, what problem are you trying to solve with it?

              Keydus Wanting to have the possibility to tell a priority in the sorting order using SkeletonRendererSeparator (as stated here : https://fr.esotericsoftware.com/spine-unity-utility-components#SkeletonRenderSeparator)

              What do you mean by "priority in the sorting order using SkeletonRendererSeparator"? Do you mean setting Sorting Layer and Order in Layer at SkeletonPartsRenderers? If so, why, what do you intend to use it for?

              Ensure that the number of separated parts is always the same (3 with 2 splits)

              If I understand correctly, by 3 with 2 splits you mean 🇦

                 0 is the skeleton
   1 is an attachment (hat or cloak depending on DrawOrder & cie)
   2 is another attachment (hat or cloak depending on DrawOrder & cie)

              No, I didn't mean that, that would make no sense. I meant if you have a skeleton with 2 slots where things should be inserted, you split your skeleton twice, resulting in 3 parts renderers:

              SkeletonPart1
- split, insert GameObjects for e.g. hat here
SkeletonPart2
- split, insert GameObjects for e.g. cloak here
SkeletonPart3

              Keydus In this whole part I don't think I'm completely following what you said about the sibling index. What should I do with them?

              This might have a been due to me misunderstanding what you are trying to do, I first assumed that you wanted to insert the hat and cloak as a GameObject item, and not as a skeleton attachment.

              Keydus I might have a solution to dynamically change the sorting order of the PartsRenderer on the animation change to apply the one calculated from the visibility (should be rendered first or last)

              The question is why do you need to change sorting order of parts renderers, see questions above?
              And first of all, why do you need a SkeletonRenderSeparator if all your items are normal attachments?

              but still I can't know which attachment/slot is rendered in which PartsRenderer

              Your Skeleton project in the Spine Editor defines the draw order, and combined with the chosen separator slots (and visible attachments) the separate parts may vary, omitting empty parts, yes.

                          Harald

                          We know that it may take some effort to reduce your code down to the required parts. Please note however that you can do that much better than we would be able to, as you understand what is necessary while we do not. Please understand that we don't have the time and resources to step through your code and see which parts are actually relevant.

                          In fact for the problem I described early in this thread, all parts are relevant for me. I took only relevant parts from my project here. I don't think I might be able to remove anymore parts to reproduce the initial problem.

                          Things are more complicated if you have two slots for each item, one per view. Is there a reason why you need separate separation-slots for front and back view?

                          There is absolutely no restrictions here. Initially, it was because I just wanted to hide the attachment (since the slot of F_hat and B_hat are always displayed) instead of removing it. However, if I have only one slot per equipment slot it might work for slots that has no attachment (like the hat which attachment is created during runtime) but won't work for the cloak that is a MeshAttachment on Spine Editor, am I right? For this specific case, I might need to keep 2 slots and 2 attachments?

                          Could you explain the motivation for using SkeletonRenderSeparator, what problem are you trying to solve with it?

                          The sole problem I try to solve with SkeletonRendererSeparator is to handle the visibility per equipment per view.

                          Here is a relevant example :

                          • I have a hat of type "mask" :

                            • F view : will be rendered in front of everything
                            • B view : will be rendered behind everything

                          • I have a hat of type "sorcerer hat" :

                            • F view and B view : will be rendered in front of everything

                          I could create a specific slots for the mask, and other slots for the hat and put it properly on the hierarchy of the skeleton in the Spine Editor to have something that match the needed rendering order but we would need to do it for every character we produce which is kinda silly.

                          In this case, SkeletonRenderSeparator seemed to be a good candidate since I can have my attachments in specific GameObjects and can handle the priority with the SortingOrder component

                          What do you mean by "priority in the sorting order using SkeletonRendererSeparator"? Do you mean setting Sorting Layer and Order in Layer at SkeletonPartsRenderers? If so, why, what do you intend to use it for?

                          Answer is just above!

                          This might have a been due to me misunderstanding what you are trying to do, I first assumed that you wanted to insert the hat and cloak as a GameObject item, and not as a skeleton attachment.

                          Yes, I want to add them as skeleton attachment so they follow the movement of the character

                          The question is why do you need to change sorting order of parts renderers, see questions above?

                          I will reformulate here to make it maybe more clear but it's to handle different types of hats/capes etc... This way, I can tell that this specific hat with ID 10 will render always behind the character, and this one with ID 20 will render always in front of the character.

                          In my head, I could just adjust the SortingOrder of the SkeletonPartRenderer

                          As told before, there might be some hats that will need this specific treatments : think about a mask vs a classic sorcerer hat

                          And first of all, why do you need a SkeletonRenderSeparator if all your items are normal attachments?
                          Because of the sorting order, still. Currently, the cloak is a MeshAttachment that is created directly on Spine while the hat is a RegionAttachment created on the fly when the player equips one

                          I hope it makes things more clear. Am I running a very special case?

                          EDIT : I omitted a part in my initial explanations so sorry for that.
                          Player is able to equip a lot of different hats and cloaks so that's why I'm adjusting things that dynamically

                              Keydus In fact for the problem I described early in this thread, all parts are relevant for me. I took only relevant parts from my project here. I don't think I might be able to remove anymore parts to reproduce the initial problem.

                              Ok, I see, then let's not fix your attempted solution but instead solve your initial problem.

                              Keydus There is absolutely no restrictions here. Initially, it was because I just wanted to hide the attachment (since the slot of F_hat and B_hat are always displayed) instead of removing it.

                              I'm not sure I understand what exactly you mean by "hide" compared to "remove". If you mean hiding them in the Spine Editor: this is not exported in skeleton exports (see the documetnation here). If you mean setting the Slot alpha value to 0.0, that will hide any attachments. That might be useful for hiding all B_ slots when your facing is forward and F_ slots should be visible.

                              What would be cleaner than setting slot alpha is using skin bones to disable any back-facing bones and their connected attachments at slots when facing forward, and vice versa.

                              Keydus However, if I have only one slot per equipment slot it might work for slots that has no attachment (like the hat which attachment is created during runtime) but won't work for the cloak that is a MeshAttachment on Spine Editor, am I right?

                              I'm afraid I don't quite understand the above, especially "one slot per equipment slot" is a bit confusing. You might mean "one separator slot for each equipment slot", but then still I'm not sure what you mean.
                              Also, whether a MeshAttachment is attached at a slot or a RegionAttachment is all still a single attachment, there should be no difference.

                              For this specific case, I might need to keep 2 slots and 2 attachments?

                              If your items require multiple bones and attachments, like with trousers, then you will have multiple slots, yes. That's what skins and combining skins at runtime can be used for. You then have a single skin for each item, setting multiple attachments accordingly. A wood-mask skin in your case could set attachments for all directions at once, while skin-bones would automatically disable anything irrelevant for your active direction (all back-facing bones and attachments).

                              See the general documentation here:
                              http://esotericsoftware.com/spine-skins#Mix-and-match
                              And the runtime documentation here:
                              https://esotericsoftware.com/spine-unity-main-components#Combining-Skins
                              http://esotericsoftware.com/spine-runtime-skins

                              Keydus Here is a relevant example :

                              I have a hat of type "mask" :
                              F view : will be rendered in front of everything
                              B view : will be rendered behind everything

                              I have a hat of type "sorcerer hat" :
                              F view and B view : will be rendered in front of everything

                              If you have special hats which draw some parts in front of everything in the same facing-direction, you would then have a normal slot hat and an additional slot hat-always-on-top. Then your animations could define the draw order cleanly and your hat defines which attachments it sets via skins.

                              Keydus I could create a specific slots for the mask, and other slots for the hat and put it properly on the hierarchy of the skeleton in the Spine Editor to have something that match the needed rendering order but we would need to do it for every character we produce which is kinda silly.

                              I think I can understand the problem you're trying to solve now: You want to avoid having to add item attachments or item-skins for each character.

                              The typical solution is to have template attachments (blank ones just to be programmatically replaced at runtime) for each item-attachment which are large enough to accomodate the largest proportions of all items. E.g. if you have a sword attachment, make it so large to accomodate both a broad-sword and a long-sword.

                              This is described here in the documentation:
                              http://esotericsoftware.com/spine-runtime-skins#Creating-attachments

                              We would strongly recommend against splitting your skeleton into multiple parts and programmatically reordering them just to set custom attachments at runtime. This would be a nightmare to maintain and also bad performance-wise.

                                          Harald

                                          What would be cleaner than setting slot alpha is using skin bones to disable any back-facing bones and their connected attachments at slots when facing forward, and vice versa.

                                          Ok, noted. That makes sense here.

                                          I'm afraid I don't quite understand the above, especially "one slot per equipment slot" is a bit confusing. You might mean "one separator slot for each equipment slot", but then still I'm not sure what you mean.

                                          Here I mean that I will have, in Spine Editor, one slot per view per equipment type (hat, cloak, boots, trousers...) I defined on my side.

                                          F_hat to display the front hat
                                          B_hat to display the back hat

                                          Equipment slot might be misleading, equipment type term is more adapted I think

                                          If your items require multiple bones and attachments, like with trousers, then you will have multiple slots, yes. That's what skins and combining skins at runtime can be used for.

                                          That's not what I meant. You told me just before that I could maybe have one slot for the hat and just switch the sprite based on the current animation playing. However, since the cloak is a MeshAttachment, it's not possible to do so? If I have only one slot for my cloak, I'll have a strange movement?

                                          A wood-mask skin in your case could set attachments for all directions at once, while skin-bones would automatically disable anything irrelevant for your active direction (all back-facing bones and attachments).

                                          It seems interesting if I understood properly. I'll catch it later on my answer.

                                          If you have special hats which draw some parts in front of everything in the same facing-direction, you would then have a normal slot hat and an additional slot hat-always-on-top. Then your animations could define the draw order cleanly and your hat defines which attachments it sets via skins.

                                          In fact, that's what I didn't want to do to avoid repeating this step for every character I create, this is cumberosme in term of maintenance. I thought that it might be trivial to set a specific rendering order for a given attachment.

                                          I think I can understand the problem you're trying to solve now: You want to avoid having to add item attachments or item-skins for each character.

                                          Yup, that's it. I think we can affinate a bit more :

                                          • I want to create a character with a facing view and a back view
                                          • The character can be equipped with thousands of different items (hats, cloaks)
                                          • Cloaks must have movements when the character moves (not only following the bone)
                                          • Equipments might be rendered in front or behind everything depending on the configuration of the sprite

                                          We will produce multiple more characters so I don't want to repeat things on Spine side and readjust previous characters.

                                          What would be the best way/setup to go?

                                          The typical solution is to have template attachments (blank ones just to be programmatically replaced at runtime) for each item-attachment which are large enough to accomodate the largest proportions of all items. E.g. if you have a sword attachment, make it so large to accomodate both a broad-sword and a long-sword.

                                          That's what we did with the cloak : since we need it to have some weighted movements, we made a big transparent one so when equipping another cloak it will follow the movement.

                                          More information here : I think that the main problem resides in the fact that there is no way to set a specific rendering order for my equipment besides creating a new slot to make it render behind everything, which I don't like since I'll have to repeat it for all characters

                                              Keydus You told me just before that I could maybe have one slot for the hat and just switch the sprite based on the current animation playing.

                                              That's not what I meant. Anyway, let's best continue with the other approach discussed below.

                                              Keydus However, since the cloak is a MeshAttachment, it's not possible to do so? If I have only one slot for my cloak, I'll have a strange movement?

                                              " If I have only one slot for my cloak" is confusing. A MeshAttachment is an attachment, and there is always only a single slot to which an attachment is attached, you never have multiple. Or do you mean that you think you need one slot and with a single MeshAttachment for each cape, as your capes are so radically different that they can't share a mesh? I would argue that most capes are pretty similar but if you think they are completely different, sure, just create different MeshAttachments for each cape-type. You would still want to attach them at the same single Slot and not create a slot per cape-type as they are mutually exclusive and only one can be equipped at any time. Note that "the same slot" can mean "the same two slots" for front and back, F_cape and B_cape if you have one cape slot per facing-direction.

                                              Could you describe why you think the MeshAttachment would have strange movement?

                                              Keydus In fact, that's what I didn't want to do to avoid repeating this step for every character I create, this is cumberosme in term of maintenance. I thought that it might be trivial to set a specific rendering order for a given attachment.

                                              If you only want to change rendering order for single slots, it's trivial, change Skeleton.DrawOrder:
                                              http://esotericsoftware.com/spine-api-reference#Skeleton-drawOrder
                                              Note that animations can also change your draw order. So you might then need to either apply your draw order change again or every frame.

                                              I would not consider this clean design for equipment items since whenever your animation wants to change draw order to e.g. move a hand from in-front to behind your hat, you will end up with a hacky back and forth between adjusting animations and Unity-side order settings, where you can't preview in the Spine Editor how things will look. Thinking of fine-tuning draw order of hair vs specific helmet types, doing that in the Unity project side by tweaking numbers and then adjusting Spine Skeletons again would give me nightmares. That's why I would recommend having template attachments which can be positioned cleanly in the Spine Editor, adjusted in draw order in animations and previewed to ensure everything is perfectly ordered. But it's up to you of course what you prefer and what your use case requires.

                                              Keydus Cloaks must have movements when the character moves (not only following the bone)

                                              You didn't mention that before, but you could either use Physics Constraints set up in Spine to let them move automatically, or use SkeletonUtilityBone with automatic hinge chain physics setup as shown in the example scene SkeletonUtility Platformer HingeChain Physics and in this documentation section:
                                              https://esotericsoftware.com/spine-unity-utility-components#2D-and-3D-Hinge-Chains-for-Physics

                                              Keydus Equipments might be rendered in front or behind everything depending on the configuration of the sprite

                                              You likley don't want to render it in front or behind everything, but at certain points in the draw order depending in the equipment item.

                                              What would be the best way/setup to go?

                                              One of the best solutions would be the one I've described in the previous posting, having template attachments for each equipment-type, and letting skin-bones control visibility of all front or back attachments.

                                              Keydus More information here : I think that the main problem resides in the fact that there is no way to set a specific rendering order for my equipment besides creating a new slot to make it render behind everything, which I don't like since I'll have to repeat it for all characters

                                              Please see what I wrote above regarding changing DrawOrder. Please also be sure to give the Slot documentation section a thorough read:
                                              http://esotericsoftware.com/spine-slots

                                                            Harald

                                                            Note that "the same slot" can mean "the same two slots" for front and back, F_cape and B_cape if you have one cape slot per facing-direction

                                                            It comes to this way because of our mutual misunderstanding. When I meant one slot, it's one slot for both F and B which makes no sense.

                                                            You didn't mention that before, but you could either use Physics Constraints set up in Spine to let them move automatically, or use SkeletonUtilityBone with automatic hinge chain physics setup as shown in the example scene SkeletonUtility Platformer HingeChain Physics and in this documentation section:
                                                            https://esotericsoftware.com/spine-unity-utility-components#2D-and-3D-Hinge-Chains-for-Physics

                                                            We have solved this using MeshAttachment, basically. It works fine and do specific movements we need.

                                                            If you only want to change rendering order for single slots, it's trivial, change Skeleton.DrawOrder:
                                                            http://esotericsoftware.com/spine-api-reference#Skeleton-drawOrder
                                                            Note that animations can also change your draw order. So you might then need to either apply your draw order change again or every frame.

                                                            This is where I do not agree. It is not trivial since animations might (should I say must?) change the draw order almost every time. In our case, for example, it changes because when running we show the sole of shoes.

                                                            That's why I would recommend having template attachments which can be positioned cleanly in the Spine Editor, adjusted in draw order in animations and previewed to ensure everything is perfectly ordered. But it's up to you of course what you prefer and what your use case requires.

                                                            Yes and I don't like either this solution because it implies to adjust the draw order for every frame which seems to be quite bad for performances when dealing with multiples characters in the same spot.

                                                            One of the best solutions would be the one I've described in the previous posting, having template attachments for each equipment-type, and letting skin-bones control visibility of all front or back attachments.

                                                            So, basically, if I summarize : there is no way to properly fix the draw order of a specific slot and so you can't tell in runtime that this slot must be rendered after (or before) everything else.

                                                            If I want to do this I must either :

                                                            • having multiple slots of the same thing but placed at different spots in the hierarchy so I can choose to put my attachment between one or them
                                                            • adjust the DrawOrder at every frame which might become a performance hole at time

                                                            If so, it answers my initial question!

                                                                Keydus This is where I do not agree. It is not trivial since animations might (should I say must?) change the draw order almost every time. In our case, for example, it changes because when running we show the sole of shoes.

                                                                I just explained how you can change the draw order, which was what you asked how to do above:

                                                                "I thought that it might be trivial to set a specific rendering order for a given attachment."

                                                                I meant that you can directly modify the position of each slot, this is easy to do, just modify the Skeleton.DrawOrder list accordingly. You seem to have meant "I want to set a draw order integer value and sort slots automatically based on this integer value".

                                                                Still I don't quite see why it would be so complicated to adjust the order in DrawOrder to get to a certain position, after a certain target slot or exchange it with a certain placeholder slot.

                                                                Anyway, I've always recommended against manually changing draw order since it's not as clean and maintainable as other solutions.

                                                                Keydus That's why I would recommend having template attachments which can be positioned cleanly in the Spine Editor, adjusted in draw order in animations and previewed to ensure everything is perfectly ordered. But it's up to you of course what you prefer and what your use case requires.

                                                                Yes and I don't like either this solution because it implies to adjust the draw order for every frame which seems to be quite bad for performances when dealing with multiples characters in the same spot.

                                                                Are you now talking about what I recommended with template attachments? This sounds as if you're still talking about the previous solution, which I recommended against. (As a side node, changing skeleton.DrawOrder could be done very efficiently and would be much cheaper than e.g. splitting a skeleton into multiple GameObject parts.)

                                                                I recommended having multiple slots to automatically always have the right draw order for each type of equipment item (separate for F_hat, F_hat-always-front, B_hat, B_hat-always-front) and for each facing direction. You then don't have to change draw order ever. You author them correctly in the Skeleton first.

                                                                Keydus So, basically, if I summarize : there is no way to properly fix the draw order of a specific slot and so you can't tell in runtime that this slot must be rendered after (or before) everything else.

                                                                You are correct in that Spine slots are not sorted automatically by Sort Order integers. Draw order is set explicitly (by design) to avoid having to sort anything by default. However just adjust Skeleton.DrawOrder accordingly if you do want to sort slots differently. Moving certain slots completely to the front or back should be rather easy to implement. If you need utmost performance, you could reserve some empty placeholder slots at the front and back and then swap your desired equipment item slots there.

                                                                Alternatively you could also modify the source code of Slot and add a int sortingOrder property which you can then read and apply sorting accordingly.

                                                                Also if you're concerned about performance of altering DrawOrder (which will not be measurable, but still), you could modify the source code and add a callback to Spine.DrawOrderTimeline which is called when the draw oder is actually modified, so you can only update when the draw order changes. Thus you would skip adjusting draw order during constant draw order frames in any animation.

                                                                Keydus having multiple slots of the same thing but placed at different spots in the hierarchy so I can choose to put my attachment between one or them

                                                                Basically yes. Just the wording "so I can choose to put my attachment between one or [of] them" is not quite what I meant. I meant that you can author these as multiple slots with placeholder attachments (e.g. multiple slots and placeholder attachments for trouser parts), which provides more than just a single insert-slot as an insertion point. But if you meant that, then yes.

                                                                Keydus adjust the DrawOrder at every frame which might become a performance hole at time

                                                                Basically yes, but see above for performance.

                                                                            Harald

                                                                            It makes it more clear on how the runtime for Unity should be altered and/or used.

                                                                            I'll try both way to check what fits our workflow the must but will keep in mind our whole conversation!

                                                                            Thanks you very much for all your explanations and your patience to tell me more about how things should go, very appreciated!