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.

Nate Alright, thank you for the insider info. I will keep it to benefit from both types of systems.

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!

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