Looks interesting. Thx a lot for information

Very looking forward to it. Have you guys considered Constraints management with this? I definitely want to see if I can apply this to hairs, but I am concerned about managing Constraints when each Hair Skin contains at least 4 strands (each with their appropriate physics profile).

We know organizing many constraints is a pain, but let's not add too much to the release that is taking extra long! We do want to get to that soon though.

@Nate
I REALLY need this!!!!
out of curiosity, is it based on Farseer Physics?

No, it's our own physics. A 3rd party library would be overkill for what we need to do, plus we need it to be very lightweight and run in all game toolkits and languages. It's relatively simple to get basic physics going, though the devil is in the details.

I just have to say the sneak peek looks dope! You guys are doing amazing things, I wish you all the best!

The good thing that you left as with pretty neat 4.1 Spine editor version which is bug free and works amazing. I would struggle with 4.0 honestly would rather work with 3.8 than 4.0

So take your time.

A little informal update: we've been doing an internal beta and it's looking good. We hope to have the 4.2-beta available in a week or two.

Below is a smattering of examples, done quickly and a little roughly, but they show some of what is possible.

First here is the old alien animation:

Here it is with physics on the head:

It works really well for any hanging parts or accessories, like Spineboy's hair. Here all of Spineboy's hair keys have been deleted and physics constraints added. Note how the hair is dynamic and responds similarly to how it was keyed (but without all that work!). It also responds across animations changes and there is now dynamic hair movement during the aim animation:

Here the platform from our Wave Principle - Animating with Spine #4 video, but without keys on the platform tail:

Here's a chain of bones that behaves similar to a whip when rotated. The bones near the end are also scaled using physics. There are tons of interesting effects that can be squeezed out of the physics! This one could maybe be used for flames in a fire. All of this movement comes from just rotating the one bone.

Here's a quick test on the mix-and-match hair, physics giving some rotation and some translation lag:

It's not limited to just accessories, it can be used on major character features, like the raptor's tail. Here is the raptor with all the tail and gun keys deleted for walk, jump, and roar. 317 keys were deleted! The tail is straight and the gun doesn't move.

It took 12 mouse clicks to setup physics on the tail and gun, giving this:

More time could be spent refining the physics settings, but this is already great. The amount of time physics saves animating things is huge AND the results are better and react dynamically. Plus since your animations have hundreds fewer keys, the data files are smaller.

Anyway, back to work we go to get it finished up. It won't be too long now!

Nate Will the the runtimes be ready when 4.2 beta debut?

There's no guarantee that all the runtimes are ready during a beta. To start, only spine-libgdx will be ready. spine-unity and the others will be ready shortly afterward, roughly in popularity order.

Nate How did your team redesign the physics differently this time around?

Just to show my excitement, but not really expecting a response to this:
I'm wondering if we'll be able to key the bones affected by physics nonetheless, kind of overriding the procedural animation, or it's either one or the other.

I guess I'll see as soon as 4.2 stable comes out

Instead of nodes with springs between them, the bone's transform properties are offset based on the bone's movement, then return to the unconstrained pose using physics. This allows you to specify the pose as normal, but have physics give you automatic overlap and follow through.

You can indeed key the bone properties constrained by physics. Physics offsets the unconstrained transform values, so you can manipulate the transform values yourself even when mix is 100%. Like other constraints, you can mix between the physics (constrained) pose and the unconstrained pose.

If all that sounds complicated, don't worry, it's quite intuitive in reality.

Looks bloody amazing!

Nate Will there be nodes with springs in-between type of physics? I have started to add that type of physics to my Vtuber application but I am not sure if I should keep that physics system.

Currently we have removed the node/springs in favor of the new system. I'm not sure they'll come back. They were useful for a few particular things, but otherwise the new system is much easier to get good results. A lot of that comes down to the unconstrained pose being what the user wants and the physics just offsetting that. With nodes/springs they often fall down or end up in a straight line.

Makes me so happy with having picked Spine up so recently to see this coming soon. Looks like a better baked and polished version of the physics motor/dynamic physics features that were in Creature2D (seems to have been discontinued ) which I used in the past for a bunch of game animation stuff, but I can't wait to get to play with this stuff with Spine's way better runtimes compared to anything else I used prior.

Was just watching Armanimation's stream and this looks more amazing than I could have imagined. V4.2 seems like it could make so much marketing bait material to advertise Spine to 2D game artists and 2D animators, and I mean this in the best way possible. Hope you get a bunch more new people pick it up for this awesome update.

A question, will third party runtime developers be able to support the beta features while this version is in beta? I know you said that the features would come to the (official I presume) runtimes in order of popularity (aside from libGDX runtime dropping first for obvious reasons) but I don't know how well this translates to runtimes that are not maintained by Spine team?

Can I somehow become a beta tester? I would love to try out and experiment and help with the process!

FatalExit Third-party runtimes will have to implement the physics constraints That is a whole issue to worry about.

We hope to get an early release soon. Then everyone can be a beta tester! We only have private builds to make sure things are working well enough to make it public. I've never understood private betas. If people want to try your stuff and report issues, limiting it to a small group means fewer reports.

3rd party runtimes can implement their own physics. Note that if they use code from our official Spine Runtimes then they must attach our Spine Runtimes License Agreement to their runtime. If that is agreeable, porting will be quite easy. If it's not, building their own physics will be a little tricky. At any rate, we'll likely port it quickly to all the runtimes we support.

I know of only a single 3rd party clean-room runtime, and they are in the process of switching over to our official runtimes. I'd hardly call that an issue to worry about.

can I test the beta version with physics? zakaroff@hotmail.com

Mario
I'm curious, which runtime is this?

We won't be giving any other access for early testing until it's fully working properly. I know it seems like it's already usable, but there are things not working right and things missing. We don't need it to be 100% finished before starting the beta, but unfortunately it's still not ready. We're working hard to get it there ASAP!

@LeonNeol The runtime is spine-libgdx. The entire Spine editor is built on top of libgdx and uses the spine-libgdx runtime. That's why spine-libgdx is always updated with new features first. The code is already up on GitHub in our spine-runtimes repository in the 4.2-beta branch, though the code pushed there typically lags behind our actual development slightly.

Nate
I mean the 3rd party clean-room runtime Mario mentioned

Oh, sorry I misunderstood. I'm not sure which Mario meant. I believe the Defold game toolkit used to have their own clean room runtime for Spine data, but they later abandoned it in favor of our official runtimes.

The runtimes are a lot of effort for us to build and maintain. It would be even more effort for a third party to do it while also keeping it a clean room implementation. Every new Spine version that adds new features means more work for a third party runtime, else their users fall behind in functionality. It makes a lot of sense to use our runtimes and let us do that hard work. The trade off is that then you are subject to our runtime's licensing terms, but I hope you find them flexible enough to not be a problem.

Any chance of collision support with this new physics system. It seems like other tools do this using circle / sphere and capsule colliders that attach to the simulated bone.

One thing with collision support though is that if you wanted to integrate it with the game world it would be nice to have a function or a callback that could give a list of collider's on the spine asset. Then we could give back a list with whether or not the collider is colliding with the world along with the velocity. So Spine could apply the collision. I am sure there are other ways to do this but this is what came to mind first.

It would also be nice if colliders could be freestanding and not attached to any bone or be attached to a separate skeleton that can then interact with other skeletons physics. That way if you want to have multiple things interacting with each other you could.

If there is no chance for a collision system built in perhaps it would be possible to add the ability to attach colliders to the bones in Spine Editor. As well as keeping the physics API open enough so that it could be implemented by the developer of games should they require it.

I am aware of the bounding box attachment but a polygon would be less efficient to compute compared to a sphere / circle or capsule.

4.2 is looking awesome, excited to give it a try. Thanks for all the work for this release.

It's almost November, and I might be looking forward to coming to the forum every day to see if Spine4.2 has released a beta version. Waiting is really a long process

@Nate Hi Nate, for example if (in mono game/xna) I would like to make a tree moved by the wind, can it be done?

Nate Mister Nate, maybe we can already try the beta version? We will look for mistakes together... ))

Hello, how is the progress of beta version? We really hope to get some latest related information

We are sorry that we cannot give you all a clear answer on when we will be able to release 4.2-beta. All we can say is that we will release it as soon as possible. Since it will only be a beta, we cannot answer exactly what features will be available at that time, and some features that were available at the time of the beta may be removed before the official release. (Although major features are rarely removed, minor features may be removed or merged into another feature). So trying to get more information at this point may only confuse you, and we hope you understand that we cannot update information often because we do not want to confuse you.

nate066 We won't have colliders in 4.2 but we're not counting it out for the future. I can say that we don't want to build an extensive physics system. That would be fun, but it's difficult and we already have lots of animation tools to build! Our physics systems aren't intended to be used for an entire game, just to give dynamics for your animations without using a lot of CPU. That said we do want to have a way to bridge the gap between animation physics and game world physics. Often that can be done by moving or following a bone. Collisions are harder. Circle bounding boxes could be a first step, as you mentioned.

Getting ahead of myself, we have plans for mesh physics after 4.2. That is where a mesh reacts to bone movement using physics. We have a prototype for that, here's an example:

Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand même

Only the bones are animated. The fish image is the mesh and bends in the simple way you'd expect. The wireframe is the mesh with mesh physics applied. It's somewhat subtle in this example, but you can see the dynamic movement in the mesh. All that movement comes from the simple bone animation and didn't need to be animated by hand! You will also be able to have some of the mesh's bones move from the mesh physics, giving you enormous power.

It's super cool, but it does use a lot of CPU. We usually try to make things very efficient but some features like clipping or mesh physics require more processing and care needs to be taken with how they are used. In comparison, the physics in 4.2 are relatively cheap and don't use much CPU.

Anyway, we continue to work on 4.2 every day. I know the wait sucks. We want to get it released as much as you want to use it, but it has to meet some minimum requirements first. Even when it feels like we're so very close, it takes a lot of time to iron out all the details, even for a beta release.

The 4.2 beta has started! We'll do a proper announcement, but for now those of you who are paying attention can give a try!

Nate we're already trying))