valahaha

There is a list of what is possible to do only in blueprint inside unreal ?

Slot color change
Runtime skin changing
Bake Atlas sprite
Root motion
Atlas repacking
Bone following

Am I correct that you want to see if this can be done with Blueprints? (I hate to say it, but it's grammatically unclear whether you meant to ask a question or what). If so, the following features are not provided:

_Bake Atlas sprite
_Root motion
_Atlas repacking

However, I am not sure what kind of functionality you envision for "Bake Atlas sprite," so depending on the content, it may be possible to achieve this using UE functionality rather than the spine-ue runtime.

Also, it should be possible to implement the root motion yourself, but it is not as easy as using the SkeletonRootMotion component provided in spine-unity.

Actually, there is no easy way to repack atlas other than the spine-unity runtime. Atlas repacking in spine-unity uses features that Unity originally had, so similar functionality is not available in other runtimes.

One thing to note about changing the slot color is that spine-ue currently has a known issue with tint colors being incorrect in normal blend mode. An issue ticket for this issue can be found here:
EsotericSoftware/spine-runtimes2319

As Mario responded that the documentation for the spine-ue runtime is comprehensive, there is virtually no functionality that is not documented. Therefore, please check the documentation carefully.

bitcat I think you want to use a one-bone, inverse-kinematic constraint to scale the bone. Driving the target bone of the IK constraint by SpineBoneNode should scale your weapon.

@Misaki I used the getter methods directly from event object and I was able to get the desired output running 4.3 Godot.

func _on_spine_sprite_animation_event(sprite: SpineSprite, animation_state: SpineAnimationState, track_entry: SpineTrackEntry, event: SpineEvent):
	print("Animation event: " + track_entry.get_animation().get_name() + ", " + event.get_data().get_event_name() )
	print("Int: ", str(event.get_data().get_int_value()) )
	print("Float: ", str(event.get_data().get_float_value()) )
	print("String: ", event.get_data().get_string_value() )

func _on_spine_sprite_animation_event(sprite: SpineSprite, animation_state: SpineAnimationState, track_entry: SpineTrackEntry, event: SpineEvent):
	print("Animation event: " + track_entry.get_animation().get_name() + ", " + event.get_data().get_event_name() )
	print("Int: ", str(event.get_int_value()) )
	print("Float: ", str(event.get_float_value()) )
	print("String: ", event.get_string_value() )

For a game engine that handles Spine 4.2 easily and cleanly, you might want to consider using PixiJS or Phaser. Both of these game engines have strong integrations with Spine and are designed to make rendering and manipulating Spine animations straightforward.

1. PixiJS: This is a 2D rendering engine that works well with Spine. It provides a simple API for rendering Spine animations and is known for its performance and ease of use. You can find more information and examples on how to use PixiJS with Spine here.

2. Phaser: This is a popular HTML5 game framework that also has good support for Spine animations. Phaser's integration with Spine allows you to easily load and play Spine animations, and it provides a lot of flexibility for game development. More details on using Phaser with Spine can be found here.

Both of these engines are well-suited for handling Spine animations and provide a relatively easy setup for game development. They also offer good documentation and community support, which can be very helpful as you develop your game.

The Unreal Engine runtime for Spine does support Blueprint control, allowing you to use visual scripting to manage animations. However, there are some limitations. For example, interacting with slots inside Unreal is not possible via Blueprints and requires dropping down into C++ and using the spine-cpp API. Additionally, some users have reported issues that may require specific Blueprint setups or additional troubleshooting.

For starting an animation on the "Begin play" event, you can use Blueprints, but it would be helpful to see an example of your current Blueprint setup to provide more specific guidance. The spine-ue4 runtime documentation provides an overview and some guidance on using Blueprints, but detailed video tutorials are still in progress.

For more information, you can refer to the spine-ue4 Runtime Documentation.

Currently, the spine-godot runtime does not provide a specific Control node for Spine animations to be used directly as UI objects. However, you can use the existing SpineSprite node within a Control node by adding it as a child. This allows you to integrate Spine animations into your UI, although it may require some additional setup to ensure proper alignment and interaction within the UI layout.

Here's a basic example of how you can add a SpineSprite to a Control node:

1. Create a Control node in your scene.
2. Add a SpineSprite node as a child of the Control node.
3. Assign the SkeletonDataResource to the SpineSprite node.
4. Adjust the position and size of the SpineSprite to fit within the Control node.

This setup allows you to use Spine animations within the UI, leveraging the existing SpineSprite functionality.

skarasuko Sorry for the confusion! Actually, it's not due to the version update for Godot, it's due to the change in slot name specification in Spine 4.2 starting with Spine 4.2.21:

Changed slot name uniqueness to the entire path rather than just the name. This affects findSlot at runtime.

https://esotericsoftware.com/spine-changelog#v4-2-21

This change was made to allow slots to be named more reasonably. For example, with the previous specification, it was not possible to name slots in the following way:

• swords/fire
• armor/fire

Previously, folder names were not used to determine whether a slot name was unique or not, so names like the one above were determined to be the same as another slot. So you had to name them like this:

• swords/sword-fire
• armor/armor-fire

It was redundant to have to repeat the same name in this way. So the specification has been changed to judge whether the name is unique or not, including the folder name. This format will be maintained in the future, so we would appreciate it if you could fix your code.

要将通过 MTKTextureLoader 加载的 MTKTexture 转换为 spine-cpp 中 TextureRegion 的 rendererObject 属性，可以按照以下步骤进行：

1. 加载外部图片并创建 MTKTexture：

      NSError *error = nil;
      MTKTextureLoader *textureLoader = [[MTKTextureLoader alloc] initWithDevice:device];
      id<MTLTexture> texture = [textureLoader newTextureWithContentsOfURL:imageURL options:nil error:&error];
      if (error) {
          NSLog(@"Error loading texture: %@", error);
      }

2. 创建自定义的 Texture 类：
   Spine 运行时需要一个自定义的 Texture 类来包装 MTLTexture。你可以创建一个类来实现这个功能：

      class CustomTexture : public spine::Texture {
      public:
          id<MTLTexture> mtlTexture;
   
          CustomTexture(id<MTLTexture> texture) : mtlTexture(texture) {}
   
          virtual ~CustomTexture() {}
      };

3. 将 MTLTexture 包装到 CustomTexture 中：

      CustomTexture* customTexture = new CustomTexture(texture);

4. 将 CustomTexture 设置为 TextureRegion 的 rendererObject：

      spine::RegionAttachment* regionAttachment = ...; // 获取或创建 RegionAttachment
      regionAttachment->setRendererObject(customTexture);

5. 在渲染时使用 CustomTexture：
   在渲染代码中，你需要从 rendererObject 中获取 CustomTexture 并使用 mtlTexture 进行渲染：

      void renderRegionAttachment(spine::RegionAttachment* regionAttachment) {
          CustomTexture* customTexture = static_cast<CustomTexture*>(regionAttachment->getRendererObject());
          id<MTLTexture> mtlTexture = customTexture->mtlTexture;
   
          // 使用 mtlTexture 进行渲染
      }

通过以上步骤，你可以将通过 MTKTextureLoader 加载的 MTKTexture 转换为 spine-cpp 中 TextureRegion 的 rendererObject 属性，并在渲染时使用它。

GameMaker 2

Version 2.3.7.606
Windows, macOS
Wed, 08 Dec 2021 20:46:38 Z

This release also raises Spine support to require v4.0. Please be aware this updated Spine runtime will require you to re-export your Spine images using v4.0 before they will work again in GMS2!

https://gms.yoyogames.com/ReleaseNotes.html

To create multiple instances of a SkeletonDrawable in Flutter efficiently, you should load the SkeletonData and Atlas once and then reuse them for creating multiple SkeletonDrawable instances. This approach minimizes load times and memory consumption. Here’s how you can do it:

1. Load the Skeleton Data and Atlas Once:

      final atlas = await Atlas.fromAsset("assets/test.atlas");
      final skeletonData = await SkeletonData.fromAsset("assets/test.json", atlas);

2. Create Multiple Instances Using the Loaded Data:

      List<SkeletonDrawable> skeletonDrawables = [];
      for (int i = 0; i < numberOfInstances; i++) {
        skeletonDrawables.add(SkeletonDrawable(skeletonData, atlas));
      }

This way, you avoid the overhead of loading the skeleton data and atlas multiple times. Each SkeletonDrawable instance will share the same SkeletonData and Atlas, which is efficient in terms of both memory and performance.

Regarding the missing section "Pre-loading and sharing skeleton data" in the documentation, it seems to be an oversight. However, the approach described above effectively covers the concept of pre-loading and sharing skeleton data.

For more detailed information, you can refer to the spine-flutter Runtime Documentation.

Currently, the Spine plugin cannot be upgraded to use UE5's skeleton and animation system. The integration of Spine with Unreal Engine's skeletal mesh system is not straightforward due to the differences in how Spine and Unreal Engine handle skeletal animations. The Spine runtime does everything from skinning to vertex deformations, which would interfere with Unreal Engine's skeletal mesh system. Therefore, physical animations and sequencer animations in Unreal Engine cannot be simply implemented by running Spine skeletal animation components inside the SkeletonMeshComponent.

For more details, you can refer to the spine-ue4 Runtime Documentation.

Mario Your translator may have caused you to misunderstand what I said.
Today, I roughly translated "Matrix4" and "Vector3" as C#,To replace the equivalent types in OpenTK
I debugged all the rendering code to ensure that all the data used by OpenGL is the same as spine-webgl
Awesome,everything works well

I think I can publish it now

2.9.1: Fix for physics not updating

gritsenko/c3_spine_pluginreleases/tag/2.9.1

Currently, rendering Spine sprites in a 3D space within Godot 4 is not directly supported through the official Spine runtimes. There is an open issue ticket for this as a future enhancement (#2135). A workaround that has been mentioned involves rendering each SpineSprite to an off-screen render target, which could potentially impact performance if you have a large number of skeletons on screen. This method is not ideal and could significantly stall the GPU pipeline. Additionally, there's a mention of using a 3D hack with Mesh3D + Texture from SubViewport, but this approach is also not recommended due to performance issues. The Spine team has acknowledged the demand for a SpineSprite3D but has prioritized other developments at the moment.

For now, the best approach to integrate Spine animations into a 3D scene in Godot 4 would be to follow the progress on the official issue tracker and experiment with the mentioned workarounds, keeping in mind the potential performance implications.

Fix it loading spine sprite at runtime

GameMaker Studio 2's support for Spine is dependent on the version of the Spine Runtimes that YoYo Games, the developers of GameMaker, have integrated. As of the information provided, GameMaker Studio 2 was last reported to support Spine Runtimes 3.8. This means that to ensure compatibility, your Spine projects should be exported using Spine Editor version 3.8 or earlier. There has been discussion and anticipation around updating GameMaker's Spine Runtimes to support newer versions of Spine, including mentions of plans to update to Spine 4.0. However, there is no confirmed support for Spine 4.2 in GameMaker Studio 2 as of the latest information available. It's important to match the Spine Editor version with the supported runtime version in GameMaker Studio 2 to avoid issues with animation and rendering.

Yes, Spine animations can be used with both the SkeletonMecanim and SkeletonAnimation components in Unity. The SkeletonMecanim component allows for the use of Unity's Mecanim animation system to control Spine animations, providing a high-level control in combination with the Spine animation system for posing and setup of the skeleton. This means that Spine bones are applicable and can be manipulated under both systems, although the way you interact with them might differ due to the nature of the SkeletonMecanim and SkeletonAnimation components. The SkeletonMecanim component is an alternative to SkeletonAnimation, using Unity's Mecanim for animation control, while SkeletonAnimation provides direct control over animations through the Spine API.

Mario thank you for the GitHub action suggestion. Has made everything a lot simpler.