Closed GoodBoyDigital closed 5 months ago
Hey folks, Mario from Esoteric Software here. Love your work on the v8 update of the official runtime. But maybe you should reconsider this PR?
You do not want to attach anything to a bone. A bone can be thought of as a container of one or more slots. Each slot is then either empty, or has a single attachment (image, mesh) active. At rendering time, we go through all the active slots with an attachment in them, and generate a mesh for them, which is added to the Spine
object, which is a pixi container. The rendering order is defined by the zIndex
on the respective mesh for the attachment of that slot.
It is much more versatile to attach pixi objects to slots instead of bones. That way you can control the rendering order, which still being able to apply the slot's parent bone's transform to the pixi object, just as it is done to the attachment meshes.
We have an open issue for that here with some more possible implementation details: https://github.com/EsotericSoftware/spine-runtimes/issues/2539
this is great feedback @badlogic, thank you! - I'm currently working on a slightly meatier PR to handle depth sorting of attachments. I will adjust to accommodate your feedback!
Hey @badlogic we have a new PR to attach to slots instead here: #10 If you get the chance to take a look that would be great
This PR allows for containers to be attached to Bones!
One note is that the attached items are not depth sorted - and always on top. This is because the spine mesh is currently rendered in one go. Will look into sorting this in a follow up PR.
also added a little helper function that returns all available bone names
spine.getBoneNames()