Currently, that's not possible out of the box with the available C++ and blueprint API we expose. The problem is that the SkeletonRendererComponent
, a subclass of ProceduralMesh
, composes meshes on the fly, using the materials associated with atlas pages set on the SkeletonAnimationComponent
. See the implementation here:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-ue4/Plugins/SpinePlugin/Source/SpinePlugin/Private/SpineSkeletonRendererComponent.cpp#L273
SkeletonRendererComponent
would have to be extended so you can set your own material instances for a specific slot. The API would probably look something like SkeletonRendererComponent::SetSlotMaterial(FString SlotName, UMaterialInstanceDynamic *Material, TArray<FVector2D> &Uvs)
. The renderer would store the material instance and associated texture coordinates for that slot name.
When a slot's attachment is renderered in SkeletonRendererComponent::UpdateMesh()
, we'd check if a custom material and UV set were set for that specific slot and use that instead of the material and UVs fetched from the slot's attachment (see https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-ue4/Plugins/SpinePlugin/Source/SpinePlugin/Private/SpineSkeletonRendererComponent.cpp#L240 for where we fetch the atlas page (material) and UVs from the attachment).
All of this is pretty involved and error prone. For one, the material instance set via SetSlotMaterial()
would have to be properly managed regarding the UE garbage collector. Also, having the API user generate texture coordinates for attachments is non-trivial.
We currently have no short or mid term plan to implement this functionality I'm afraid, exactly because it is so involved and error prone.