Hi
In a previous version of spine from pixi themselves, we used following to add a child to a pixi container/sprite:
const sprite = this.spine.skeleton.findSlot('empty').currentSprite as Pixi.Sprite;
sprite.addChild(sprite);
In current version from esotericsoftware I cannot seem to do the same. I can find the texture like this:
const sprite = (this.spine.skeleton.findSlot('empty')?.attachment as any).region.texture.texture as Pixi.Sprite;
But that does not seem to work.I would like to have the container of that slot so I can add my sprite as child.
We sometimes add text that needs to be updated to a slot as pixi container, so we have control over them and they get the correct position in the animation. We would like to update our code and make this work with the latest version. Does somebody know how to do this?
Thanks in advance.
Pixi sprite as child of slot in spine-pixi-v7?
Spinebot I tried this, but slot.addSlotObject does not exist on type Slot or maybe the method is not public.
Hello! The bot's answer was almost correct, but it used the addSlotObject method on the wrong object. This method should be used on the Spine object itself.
You can find more details about this in our spine-pixi documentation.
Additionally, you can check out this example, which demonstrates its proper usage.
Davide
Hi Davide,
I had tried that, but I did it the wrong way. I added 3 objects separately instead of putting them in 1 container and added that as slot object. I corrected that mistake and now it works better
But if I us getSlotObject first to get the container (and first child for empty pixel image we used in old version) and add my text like that, It doesn't show anything. If I add that same container with addSlotObject, I see the text but not like it did before. Like the info says it should not do anything if the container already exists:
But all animations applied to that slot seem to be gone. We start the child image of that slot disabled few milliseconds until the time comes that the object has to show.
Now you already see the text before it should be shown. I'll some gives before and after below.
It seems that there is no child in that slot (because it says undefined), is it because it is disabled and can only be used when the animation enables it?
I'm not sure I fully understand your problem. From what I gather, you want to link the visibility of the attachment (the transparent pixel image) to the visibility of the Pixi Container.
The slot object feature does not handle this automatically. However, you can achieve it by providing a custom afterUpdateWorldTransforms method.
Here’s how you can do it:
const slot = spineObject.skeleton.findSlot("empty");
spineObject.afterUpdateWorldTransforms = () => pixiObject.visible = Boolean(slot.attachment);In this code, pixiObject refers to the container you added using addSlotObject.
By adding this snippet, the container's visibility will always stay in sync with whether the slot has an attachment or not.
If I did not understand you question, please write your message in your own language. The forum has an auto translate button that works pretty well.
Davide
I'm sorry if my explanation was a bit all over the place, but that is EXACTLY what I needed The afterUpdateWorldTranforms trick did it!
It's a bit more code than the previous Pixi version of the spine implementation, but it doesn't matter. We will look into changes in the Spine animation itself to handle this differently for the next projects, as it was a bit of an old method.
Thanks for the help!
You’re not the first user to request syncing attachment visibility with a slot object. See this example. While the code required to achieve this is only a couple of lines, I understand it can be inconvenient to implement manually.
I believe it would be wise to introduce an option to automatically sync attachment visibility with the slot object. To address this, I’ve opened an issue here to propose implementing this functionality.
As a general note, using a transparent pixel image as a texture placeholder is a clever approach, especially for elements that are not frequently attached. However, using slot objects can potentially disrupt batching and reduce performance, particularly if the slot object is positioned between two Spine attachments.
That said, for elements that are only occasionally attached, this is a perfectly reasonable solution.
Davide
Thank you for the info and the proposal on github. We only use it on 1 Spine object that only shows now and then, but we will have a look if we can indeed improve on this 
Performance is key.