Цей сайт найкраще переглядати в сучасному браузері з включеним JavaScript.

Fastest way to update material

ImpactBlueStudios

What is the quickest way to switch out the material on a SkeletonAnimation without calling Reset() and reloading all the skeleton data?

I've tried changing the renderObject on every attachment but that seems to affect all instances of the skeleton animation rather than the individual.

ImpactBlueStudios

Nate

The usual way to do this would be to use an atlas with two pages, then change the attachments to those using images from the other page (changing the skin is an easy way to do this). This has the benefit that your two sets of attachments don't have to be the same size or attached in exactly the same place.

If you are changing material for some effect or because you have many materials and don't want to do the work of attaching the image for each in Spine, then you would need to create new attachments just for the skeleton instance you want to change. Attachments from the SkeletonData are shared by all skeleton instances. Creating a new attachment can be a bit of a pain to get right. You'll need to do the work that AtlasAttachmentLoader and SkeletonJson are doing to configure the attachment. Just copying an attachment and changing the renderObject should be easier though.

ImpactBlueStudios

Thanks for getting back to me Nate.

So I've written a custom shader which will hue shift specific parts of my atlas to be able to color customize the character as shown below.

Loading Image

Although the texture in each character is exactly the same, the materials need to be individual instances because of the different properties that gets passed into the shader.

I've managed to speed up initialization by programmatically cloning the default skin with a new atlas containing a unique material instance. Unfortunately I have had to change a code in the FFDTimeline which checks that the attachment matches the attachment in the current skin.

      override public void Apply (Skeleton skeleton, float lastTime, float time, List<Event> firedEvents, float alpha) {
         Slot slot = skeleton.slots[slotIndex];
//         if (slot.attachment != attachment) return;

I think because the SkeletonData is stateless and shared accross all Skeleton instances, the FFDTimeline.Attachment needs to be able to work with multiple skins with different attachments as long as they have matching slotIndexes. I also had to add a custom Reset method in SkeletonRenderer which will initialize the private variables and create a new skeleton without reloading the SkeletonData from JSON.

Nate

That looks super cool! 8) Kudos for bending the renderer to your will.

FfdTimeline only works for a specific attachment because other attachments may not have the same mesh. Also, there may be multiple FfdTimelines for attachments with different meshes for the same slot.

Check this task and especially the thread linked from it:
https://trello.com/c/ljyJfNVt/63-way-to ... -be-reused
The way this would work is that the slot would store state for what region the attachment should use. This is similar to how the slot stores other attachment state, eg for mesh FFD vertices or attachment time. This allows the attachment to remain stateless, but the region it uses can be customized per skeleton instance.

It may be some time before I can get to this for all the runtimes. You could implement this yourself, just add a field to slot and edit the renderer to use it. If you are changing the material for all attachments on your skeleton, you could hack the renderer to have a Material field instead of using the Material from the Atlas. This is probably easier than duplicating attachments and won't have issues with FfdTimeline.

There may be some issues with the slot state approach, since it is just an idea and the implementation hasn't been fleshed out. Eg, it may not work well if your animations are swapping attachments. Presumably the state set on the slot is attachment specific and lost when the attachment changes, as attachment time and vertices are. Maybe another solution is needed. Maybe there is something that determines the material for an attachment. I'd like the editor to be able to key changing the region for an attachment, so however the solution works should be compatible with that.