Spine Meshes Question

Andaharoo

Considering upgrading to spine pro for meshes and deformations. But I have a question. Are the mesh vertices exposed in the runtime so I can edit them? I want to program some sort of dynamic reaction to physical forces. IE: Make all the vertices in the mesh particles and move them according to some physical model to simulate things like a tree blowing.

Can I just get the attachment from the skeleton on update and alter the vertices?
skeleton.GetAttachment("example").vertices[0] += 10; // Move first vertex 10 along x
Then update the skeleton as normal?

I don't have any simple spine meshes I can test and the trial doesn't let you save files so I can't save one.

Pharan

Yes, you can do that.

MeshAttachments derive from VertexAttachment (spine-runtimes/VertexAttachment.cs at 3.6)
You can access .Vertices property, which is an implicit array of Vector2 as a float[] (i*2 is x, (i*2)+1 is y)
Note that these values are local to the parent bone of the slot that holds the MeshAttachment. So it will pass through a transformation before being rendered.
Also note that since json loading is scaled by 0.01 by default in Spine-Unity, you'll sort of be moving the vertices in Unity units rather than Spine units/pixels.

Note that the above is not true if your mesh has WEIGHTS.
Traversing the vertices array is more complicated in that case as it also stores the number of bones weighted to that vertex, the bone indices and the weights. Also in this case, the transformation is applied via bone weights instead of the slot's parent bone.

Andaharoo

Pharan đã viết
Yes, you can do that.

Is it possible to get the MeshAttachments to copy without copying textures? IE: If I load in a single animation of a tree then make 1000 instances of that tree like so:
tree.skeleton = new Skeleton(baseSkeleton.Data);
tree.state = new AnimationState(baseState.Data);

Then each can have an independent animation.

But mesh attachments don't work like that. They all share the same attachment it seems so modifying tree[0].skeleton.GetAttachment("slot", "attachmentName") moves all instances.

Additionally I noticed I could change the color of a RegionAttachment even though they are copied? Further confusing myself.
(skeleton.GetAttachment("...") as MeshAttachment).vertices[0] += 10;// Changes every other animation that uses this attachment
(skeleton.GetAttachment("...") as RegionAttachment).R = 1f; // Changes only one

Pharan

Ah. Attachments are stored at the SkeletonData level and shared across all instances. This is so that if you have multiple of that skeleton, it doesn't need to instantiate all the data that doesn't need to be unique anyway.

For VertexAttachments, deformations are temporarily stored in slot.AttachmentVertices which is at the skeleton level (unique to each Skeleton instance). I forget how its contents are encoded. I'll get back to you on that.

edit: For non-weighted meshes, slot.AttachmentVertices is encoded similar to the vertices on the MeshAttachment itself. Just ensure that its size is exactly the same size as the vertex array of the MeshAttachment. AttachmentVertices is an ExposedList<float> so you have to get its .Items to get to the float[].

// For non-weighted meshes.
int verticesLength = meshAttachment.worldVerticesLength;
var slotVertices = slot.AttachmentVertices;

if (slotVertices.Capacity < verticesLength) slotVertices.Capacity = verticesLength;   

slotVertices.Count = verticesLength;
floar[] vertices = slotVertices.Items;

//... loop
vertices[i*2] = x;

But in all other cases, you would probably have to clone both the (default) skin of that skeleton, and clone the attachment you are trying to modify so both can exist per skeleton.

If you are using Unity, there are cloning extension methods you can access through using Spine.Unity.Modules.AttachmentTools. Not sure yet if the cloning methods on the base runtime will make it into 3.7 release. A lot of this API is part of a "skins and attachments" improvement we have planned. Spine-Unity is currently the only runtime that has something that can be used in the meantime.

In Unity, the code would look like this:

void CloneSkinCloneAttachmentExample (Spine.Unity.SkeletonAnimation skeletonAnimation) {
   var skeleton = skeletonAnimation.Skeleton;

   Spine.Skin defaultSkin = skeleton.Data.DefaultSkin;
   Spine.Skin activeSkin = skeleton.Skin;

   // Clone skin. Combine both default skin and active skin.
   var newSkin = defaultSkin.GetClone();
   activeSkin.CopyTo(newSkin, true, false, false);

   // Find, clone and reassign the target attachment.
   int slotIndex = skeleton.FindSlotIndex("slot name");
   string keyName = "attachment name";
   Spine.Attachment attachmentToClone = newSkin.GetAttachment(slotIndex, keyName);
   Spine.Attachment clonedAttachment = attachmentToClone.GetClone(cloneMeshesAsLinked: false);
   newSkin.SetAttachment(slotIndex, keyName, clonedAttachment);

   // Assign skin
   skeleton.Skin = newSkin;

   // At this point, clonedAttachment can now be modified
   // and not affect other Skeleton instances
}

Here's a test skeleton with a single MeshAttachment with verts arranged in a 3x3 grid. The slot and attachment name is "__whitesquare":

Andaharoo

Using the attachment vertices didn't do anything. They don't seem to be ever used/changed? (threw some breakpoints in and checked if it was ever changed during deformation)

I don't use unity. Will AttachmentTools.cs ever be adapted for csharp/monogame(xna) They don't seem to be in the 3.7 beta branch. Unless they were added elsewhere.

Pharan

1.
Here, you'll see where spine-xna's SkeletonRenderer calls MeshAttachment's (which is VertexAttachment's) ComputeWorldVertices.
spine-runtimes/SkeletonRenderer.cs at 3.6

Here is where it's used in VertexAttachment.ComputeWorldVertices
spine-runtimes/VertexAttachment.cs at 3.6

Internally, the same slot.AttachmentVertices is used by animation deform timelines to apply vertex data from animations onto the skeleton:
spine-runtimes/Animation.cs at 3.6

So if there happens to be a deform animation being applied to that slot for that attachment, it may overwrite your manual changes.

2.
AttachmentTools is part of Spine-Unity.
Some parts of it does generic C# stuff. Mostly as mentioned in that link, those parts are likely to make it into the base spine-csharp when it's applied to all other runtimes.

The rest of it does Unity-specific stuff such as adapt and juggle Unity types (meshes, sprites, textures, etc) to fit into Spine skeletons and skeleton data.
I'm afraid I don't know enough about XNA/monogame to know how or if those can be or make sense to adapt there.