No physics constraint class in spine-godot.

BBayagototh · 23 авг 2024

Hiya! First post so apologies if the tags aren't right. I've been working with the spine-godot runtimes for a few days and I'm approaching the implementation of physics for the SpineSprite. Is it intentional that you cannot access physics constraints at runtime? From the SpineSkeleton, you can find IK, path, or transform constraints, but not physics constraints, and there is no physics constraint class. Is that something for another milestone, or is it an intentional limitation?

Also as an aside, why separate SpineEvent and SpineEventData into two classes with very similar functions. It feels odd having to get_data() my event just to get the event name, while all the other data is immediately fetchable. Spine-godot is great though and even though I was pretty spooked by Spine's price-point, I've been LOVING it. Really haven't run into a single "wish that was a feature" since physics rolled out.

Spinebot · 23 авг 2024

Regarding your question about physics constraints in spine-godot, it appears that the current implementation does not support physics constraints directly. The documentation mentions that you can access IK, path, and transform constraints from the SpineSkeleton, but there is no mention of physics constraints. This could be an intentional limitation or a feature planned for a future update. Unfortunately, there is no specific information available about the inclusion of physics constraints in upcoming milestones.

As for the separation of SpineEvent and SpineEventData into two classes, this design choice is likely made to distinguish between the event instance and its static data. SpineEvent represents an occurrence of an event during animation playback, while SpineEventData holds the static data defining the event. This separation allows for more efficient handling and reuse of event data across multiple event instances. While it may seem cumbersome to call get_data() to access the event name, this design ensures a clear distinction between the event's occurrence and its definition.

Thank you for your positive feedback on spine-godot! It's great to hear that you are enjoying using it despite the initial concerns about the price point.

Mario · 27 авг 2024

Apologies, that omission is a bug. I've opened an issue here:
EsotericSoftware/spine-runtimes2612

Out of curiosity, what are you trying to do with the constraint directly?

SpineEventData is the base data all SpineEvent instances share. I.e. you may have multiple skeleton instances of the same SpineSkeletonDataResource. They each may play an animation at different times, which emits events. When such an event is emitted, you get a distinct SpineEvent for each skeleton. It holds the event's data at the point in time in the animation for that specific skeleton, which will differ from the that of the other skeletons.

Regarding the spooky price-point, consider that it's a one time payment and you get updates for life and first class support, irrespective of whether you are a hobbyist or part of a big studio. Compare that to subscription-based software

BBayagototh · 6 сен 2024

Mario
Yeah, it's definitely a "I'm not used to buying professional software" thing, I forget that most software comes in subscriptions of hundreds a year/month or similar, and only get worse if you actually start profiting from their use.

Regarding changing the data on a phys constraint, it's for the sake of modifying physics based on environmental things, like the gravity on environment, wind for motion/environmental wind, restricting how intensive a phys bone is based on other active skins (I believe my initial need for that one was hairclips in hair). Player customization is sorta the name of the game for me, it's the whole reason I was willing to drop money on Spine, there's just no better way to scale that lol. I considered doing animations which I'd just put on a higher track to restrict/change those parameters, but utlimately with enough different skins for hair/clothes/whatever, it'd get a little tumultuous to be picking through all of those constraints and adding tracks for all of them. It is my temp fix for now though.

BBayagototh · 7 сен 2024

Bayagototh Actually, an addendum, in the Spine editor, physics constraints simulate with respect for the time scale of the skeleton when checking previews. However in Godot, the physics are not synchronous with the animation state time scale. For example, if the animation is paused by setting the time scale to 0.0, physics will still simulate at a normal rate, as if it were 1.0.

Mario · 9 сен 2024

Hm, skeleton's themselves don't really have a timescale. The animation state and its track entries do. The skeleton is oblivious to the time scale on the animation state, so if Skeleton::update(deltaTime) is called, it just gets added to an internal accumulator, which is then used by physics constraints to do their thing.

To complicate matters more, individual track entries in the animation state can have individual time scales (which get multiplied with the time scale on the animation state, it's time scales all the way down...). So, depending on which and how many animations you mix with different time scales, there might not be a single time scale applicable to the physics constraints that matches whatever the setup of the animation state and track entries is.

Long story short: if you apply time scale to the animation state or individual track entries and need physics constraints to match that time scale, you'll have to manually apply that time scale when calling Skeleton::update() on the C++ side.

In GDScript, you have to set the SpineSprite update mode to manual and override the SpineSprite._process() or SpineSprite._physics_process() methods. In those, you'd manually call SpineSprite::update_skeleton(delta * time_scale) to apply the time scale to your physics constraints. See also:
https://en.esotericsoftware.com/spine-godot#Setting-the-Update-Mode