Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

[spine-ts] Applying global physics

martinr

We have spine skeletons attached in some hierarchy of nodes. So we may move the skeleton without doing anything on the skeleton, which has worked fine until now.
Now we want to update the skeletons physics based on global movement. Fx if we move a parent node of the skeleton, we want the physics of the skeleton to react to that movement. How do we best achieve that?

Currently, we have this solution:

skeleton.updateWorldTransform(Physics.none);
skeleton.updateWorldTransformWith(Physics.update, worldBone);

Where worldBone is set up with the global transform of the skeleton.
This solution works, the only caveat is that worldBone is created like a plain javascript object:

worldBone = {
    a: aValue,
    b: bValue,
    c: cValue,
    d: dValue,
    worldX: worldXValue,
    worldY: worldYValue
};

The Bone constructor requires some data and a skeleton which is not necessary for this use case, so we use a simple object and then have to add a typecast to make the compiler happy. Is there a better method for achieving this behavior?

Davide

martinr

Hello!

If you move your game object and not the skeleton, you can use physicsTranslate. Have a look at this spine-pixi example.

There, we move the game object, convert the position from screen world to spine world, and eventually invoke physicsTranslate to trigger the physics constraint as if the skeleton was moved.

Spinebot

To achieve the desired behavior of updating the skeleton's physics based on global movement, you are on the right track with your current solution. You are using skeleton.updateWorldTransform(Physics.none) followed by skeleton.updateWorldTransformWith(Physics.update, worldBone), where worldBone is a plain JavaScript object representing the global transform. This approach effectively updates the physics without directly modifying the skeleton's internal bone structure.

While using a plain JavaScript object for worldBone is a practical workaround, it is not the most elegant solution due to the need for typecasting. Unfortunately, there isn't a built-in method in Spine to directly handle this scenario without using a Bone object. However, you could consider creating a utility function or class that encapsulates the creation and management of these global transform objects, which could help streamline your code and reduce the need for typecasting. This utility could handle the conversion of global transforms to the format expected by Spine, making your code cleaner and more maintainable.

martinr

That makes sense, however, since we already have a calculated transform, to me it seems simpler to just use the approah we are already using. Otherwise, I would have to calculate a translation based on a global transform which also holds rotation, scale and shear which would have to be accounted for. If I use the "parent bone" method, that is all given to me, right? It is also an absolute value rather than relative to the previous update, which is also what we want.