yugutou Thanks for reporting this issue! It seems that either the default FPS change added in 4.3.17-beta or the physics smoothness improvements added in 4.3.15-beta may be causing this. Could you please check if changing the FPS in the Physics Constraints properties fixes the problem?

This was a bug, thanks for letting us know! We've fixed it in 4.3.18-beta.

yugutou 4.3.18-beta is now available! We hope you can confirm that your issue has been resolved.

yugutou We apologize that this issue has not yet been resolved. Yes, sending us the actual spine project file would be helpful for our investigation: contact@esotericsoftware.com

yugutou Thanks for providing the Spine project file! I exported a MOV file using Spine 4.3.18-beta and checked it, and while there were some minor differences, it did not appear that the differences were significant enough to suggest that only the MOV file was incorrect, since only the preview in the editor was changed. So if the viewport state is correct, it does not appear that there is a problem with the MOV file alone. I have sent an email with a video for comparison, could you please check the attached video?

Thanks for sending the project and the comparison video.

When playing an animation in the editor with physics Deterministic unchecked, the physics is updated all the time, as allowed by the rendering rate of the editor. When checked, physics is calculated more precisely and you will always get the same pose on a given frame. That uses a lot more CPU, especially for a project as complex as yours. When you export MOV (or any other image/video) the physics is calculated like when Deterministic is checked. This means you may see some slight difference in the editor when Deterministic is unchecked compared to MOV.

That said, that is not the reason for the bigger differences you see in your project between 4.3.14-beta (which has physics identical to 4.2) and 4.3.18-beta. We changed physics slightly to fix it being choppy when the render rate is low.

To see the problem we fixed, in 4.3.14-beta try playing your animation using 10% speed in the Playback view. Especially for larger movements, like the tip of the hat, the movement is very choppy. It's most noticeable when something is moving in a straight line. If you try the same in 4.3.18-beta you'll see it is extremely smooth, which is great!

Unfortunately to make it so smooth, physics behavior is slightly different. In our testing most skeletons using physics don't need any changes. In projects like yours that have a long nested chain of bones that all have physics, a very small difference in movement for each parent bone can add up to a larger difference for child bones deep in the hierarchy.

Physics forces are applied at a fixed rate. That's the FPS setting for the physics constraint. We used to just apply the whole force. This looks OK when the rendering rate is near the physics rate, but when the rendering rate is lower, the multiple frames are drawn without new physics forces being applied. Then, when the forces are applied, the bone jumps to the new position. What our change does is that forces are not applied right away. Instead they are applied over the next physics step.

For example, at 60 FPS the physics step is 1 second / 60 frames = 16ms. A force is calculated during a physics step, but not applied yet. If the rendering rate draws 4 frames for every 16ms, the rendered frames will see 25%, 50%, 75%, and 100% of the force. That makes the rendering very smooth, but it means that forces are delayed. Worst case they are delayed one physics step (16ms) and on average they are delayed half that (8ms).

This is normally such a small difference that it doesn't matter, except in long bone chains as mentioned. For projects where this causes undesirable behavior, unfortunately you will have to manually adjust the physics constraints to get the behavior you want.

The easiest way to fix your project is to increase the physics FPS. At 120 FPS the physics step is 1 second / 120 frames = 8ms, so the delay is 4ms on average and the difference with the old physics is half as much.

Another way to fix it is to increase the strength of your physics constraints to compensate for the slightly delayed forces.

We deeply apologize that this physics change requires manual fix up! We try to avoid that at all costs, but the improvements in smoothness for physics are very important.

yugutou 是指把限制提高，或者把fps提高到120吗？

You can increase FPS to fix it. Or you can increase strength, this one:

Изображение удалено из-за отсутствия поддержки HTTPS. | Показать

yugutou 之后我该怎么让我在spine看到的跟导出的效果一样。

It should be the same when you check Deterministic, this one:

Изображение удалено из-за отсутствия поддержки HTTPS. | Показать

4.3.14 比较稳定、4.3.16 很多小问题。后面版本没试
物理的话我一般限制低于1000、设置的fps至少是输出的两倍。不过为了方便都是直接120fps了。
另外再更高的运动下、物理很难往子骨骼去传到、导致尾端就是会硬、降低惯性、加大力量、减少质量也一样。这种极端的情况下建议是高帧率输出、后面时间重映射。比如预期30fps、你摄影表以120fps预览。物理fps设置240。得到一个正确预期的物理之后再抽帧。
如官方nate说的一样、启用确定性确定查看预期的渲染效果。不过不适合预览、因为越到后面计算量越大。
其次造成物理卡顿的还会有一种可能就是官方默认的曲线采样两帧之间是10段。可能你得看情况卡点。这个我倒是提过。可惜被以性能优先含糊过去了。
另外再实践中、拉高质量、惯性的话可以适当降低力度和装配。很多情况下默认加混合就能达到一个不错的效果。如果更好点的话是根骨骼到子骨骼的惯性递增。20_{50的样子。另外我一般会K一次待机}(幅度小一点)再加上物理的样子。这会有预期的错开且不太离谱。
说白了、要更好的效果就更花时间。看你自己

yugutou
大概可以这样理解：下面的参数是描述骨骼的物理。上面的装配是实现骨骼物理用的。
最后具体效果还是得根据需求实际调整。
扇面说的只是咱总结出的一些规律而已。物理这玩意儿没有绝对正确。都是调好看了就用。
如果能像L2D一样完整烘焙的话、可以有更多的调节空间倒是

In 4.3.23-beta we improved physics smoothness and responsiveness. It should now behave like it did in 4.2, except it's extremely smooth! It's stays smooth when the render rate is much higher than the physics rate.

We tested on the project you sent and it behaves well, the hat doesn't bend strangely like it used to. It looks good even with a physics FPS as low as 10 (too low gets unstable and everything explodes). Even when the playback speed is 10%, the physics movement is perfectly smooth!

Here's a comparison of the 4.2 editor vs 4.3 editor vs 4.3 runtime showing Spineboy with physics on his head bone, with playback at 10% speed:

4.2 is really not good when the render speed is higher than the physics update rate. I'm super happy we were able to fix it AND keep nearly identical physics behavior.

If you already updated your project to work with the 4.3 physics before 4.3.23-beta, I'm sorry! Maybe you can go back to a backup file.