4.2-beta status update
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.
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
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 removed due to the lack of support for HTTPS. | Show Anyway
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!
Oh, Nate, the new version of the laptop is really amazing. Would you consider adding a storage preset function for future physical functions so that changing parameters can be faster
When Deterministic is checked, the pose you see in the editor is the result of applying the animation and physics many times from frame 0 to the current frame. This gives you a consistent pose for any given frame. Since posing physics always starts at the first frame of the animation, you can scrub back and forth on the timeline and see the physics rewind. Also you can animate more easily, without physics floating your bones all around, but while still having effects from physics.
It will cause a jump at the end of looping animations. For loops you may want to leave Deterministic unchecked.
The downside to checking Deterministic is that Spine has to do a lot of work to pose each frame, and the work increases the higher the frame is on the timeline. On my quite powerful computer, my Spine editor starts to drop below 60 FPS at about frame 1100 (~37 seconds of animation) on a skeleton with 52 physics constraints, all set to 60 FPS. At runtime or when Deterministic is off, physics are very efficient. I have never see a framerate drop from physics alone, even with 100 physics constraints. Deterministic causes a frame rate drop because it's both applying the animation and physics many hundreds or thousands of times for every editor frame.
Deterministic only affects the editor. At runtime your code can "fast forward" physics like this, if you want. Your code can also control when physics are reset, or you can reset physics by keying the reset with the Reset and Reset All buttons in the Spine editor.
Nate The parameter names in physical constraints are a bit confusing to me. For example, inertia and mass are equivalent in the real world, but the inertia here seems to be used to control vibration amplitude. Mass and Strength have the same effect in controlling vibration frequency. Wind and Gravity are the same thing but in different directions, why not use the same name and separate X and Y? And they seem to be just external forces that cause the spring oscillator to deviate from its initial position, so I don't know how to set the parameters if I want to simulate free falling motion.You may update the tutorial soon, could you please briefly explain it if you have time?Thank you very much.（This paragraph uses machine translation）
- 수정됨
habahu inertia and mass are equivalent in the real world
In the real world they are related and inversely proportional, but aren't equivalent. Our physics constraint has to fudge a whole lot of things so real world accuracy isn't the goal, but the names should make some sense. We are open to improving the names.
For physics constraint, inertia is not used when applying forces, instead it is used when a bone moves and the physics controlled properties (x/y/rotation/scaleX/shearX) need to be adjusted to simulate lagging behind the action. The constrained pose from physics constraint is achieved by "offsetting" the properties from the unconstrained pose based on bone movement. Inertia controls how much bone movement is transferred to the properties' physics offset. 100% inertia means the property's offset is affected maximally by the bone movement, 0% means it is not affected at all.
Spring forces are applied over time to reduce the physics offset to zero, effectively causing the constrained pose to (try to) return to the unconstrained pose. Mass (1 / mass actually) is use to scale those forces (Newton's second law: force = mass * acceleration). Given the same amount of force, a larger mass is affected less and a smaller mass is affected more.
habahu Mass and Strength have the same effect in controlling vibration frequency
All of the properties are interconnected, so changing one affects the others. You can achieve a reduction in oscillation multiple ways. Damping is most straightforward, but you can also use less strength, making the forces returning the offset to zero weaker and therefore less likely to overshoot zero. Mass is a multiplier for the forces, so it can also make them weaker to reduce oscillation.
Tuning physics is a bit of an art. Many different behaviors can be achieved with various slider configurations. Some of them give similar results but there can be subtle and not so subtle differences.
habahu Wind and Gravity are the same thing but in different directions, why not use the same name and separate X and Y?
By the same name do you mean windX and windY? I prefer the names wind and gravity. People don't often think about wind in the up/down directions. The 2 sliders could be placed in the UI on the same row to reduce vertical space, but would be the only sliders placed that way and would require the tree to be wider to make them usable.
habahu they seem to be just external forces that cause the spring oscillator to deviate from its initial position, so I don't know how to set the parameters if I want to simulate free falling motion.
Enable translate Y and set gravity so you have a downward force. Strength is what returns the property to the unconstrained pose, so set strength to zero and your bone will fall downward forever. Set damping to zero (or near zero) so gravity's constant acceleration results in a continuous linear increase in velocity (ie it falls faster and faster over time).
Nate Tuning physics is a bit of an art.
Agree 
One note from me. While Gravity is fine I think wind is misleading When I see wind I expect cool stuff to be simulated with wind but in reality I should do the heavy work animating the strength of the wind to make it seem like a wind. So in general without collision maybe gravity is also sounds big. we could strip those 2 properties. It would simplify the view. Anyway I mostly did not use them so far. We can add a force with its direction if we wish, by just hitting Add Button
