Serialization and Physics Constraints

NngSliver · 2 мая 2024

Hi, I've been using spine2d for a while now and just have a quick question about serializing animations with physics constraints.

I already have a serialization of AnimationState that recreates all the tracks and the pointers between them, it seems to work correctly as long as there aren't any physics constraints at play. I've noticed that now skeleton.cpp has a _time variable that gets updated at runtime and it seems to be important for physics constrains, and it also seems to me that the _physicsConstraints themselves might be storing data that might need to be saved (probably everything that's inside the reset() method).

So, my question is, provided that AnimationState is properly serialized, would serializing skeleton._time and all the _physicsConstraints data suffice to be able to recreate the exact pose at the moment of saving?. would any other variables be needed? or, in order for it to work would I need to completely save the entire skeleton state with all its bones (as opposed to just the AnimationState)?

Spinebot · 2 мая 2024

To recreate the exact pose at the moment of saving, especially when physics constraints are involved, serializing the AnimationState alone might not be sufficient. The AnimationState serialization captures the animation tracks and their settings, but it does not account for the dynamic effects introduced by physics constraints. The _time variable in skeleton.cpp and the state of the _physicsConstraints are indeed important for accurately reproducing the physics interactions at a specific moment.

However, the discussions in the provided contexts do not directly address the complete requirements for serializing physics constraints alongside AnimationState. They do highlight the complexity of serializing game state, including animations and physics, suggesting that a comprehensive approach might involve more than just AnimationState and _time. For physics constraints, which depend on previous poses to calculate velocities and other dynamic effects, you might need to serialize additional state information that captures these dynamics.

Given the complexity of physics simulations, which can depend on continuous states rather than discrete events, serializing the entire skeleton state, including all bones and possibly other physics-related data, might be necessary for an accurate recreation. This would ensure that all the nuances of the physics interactions are preserved, not just the animation poses.

Mario · 2 мая 2024

As Spinebot said, you are mostly spot on. Besides the AnimationState and the Skeleton._time, you'll also have to serialize the state of all PhysicConstraint instances. The fields that are modified in PhysicsConstraint::reset() will likely not suffice though. You will also need to serialize ux, uy, cx, and cy. These retain any "external" force that was applied to the skeleton via e.g. Skeleton::physicsTranslate(), which subsequently influences the physics constraints.

Nate · 2 мая 2024

While doing as Mario said will reproduce the same pose from physics, physics shouldn't generally be relied upon to be exactly the same on different computers. Deviations in the timing from frame to frame can result in different physics results. If you use serialization to sync remote animations, you may get some snapping if you don't do it often enough.

NngSliver · 2 мая 2024

It seems to be working correctly after I serialized all the _physicsConstraints and _time. The use case is a planned game with fixed delta time and rollback netcode, so it will both sync very often and the frames should all be the same size. The new physics constraints look really well, you guys have been doing an amazing job with Spine.

Thanks for the help.