如果我在眼睛的高光晃动、眼睫毛的摆动、眼球的缩放这些地方做了物理,头部运动会让这些物理运动的特别明显,然而我只想让它在眨眼的时候起效,而不受到身体物理的影响。按照live2d那边的思路是给这个物理添加触发骨骼,只有触发骨骼本地的值发生变化才会触发这个物理的运动。
希望可以给物理约束添加个触发骨骼,默认没有的情况就是按照原来的物理解算方式运动,添加了触发骨骼的情况只有触发骨骼运动的时候会触发对应的物理约束

    Related Discussions
    ...

    It's an interesting idea to specify a bone to take movement from, rather than the bone physics will modify.

    Spine physics are based on world transforms. If we used the world transform for the other bone, it would still give movement when the body moves. I know that is not what you want, but I wonder if it might be useful in some cases?

    If we used the local transform of the other bone, it would not be affected by movement of the body. However, you may have trouble getting a realistic effect. You may have to manage moving the other bone to get the effect you want. Or possibly give the other bone its own, different physics.

    We'll give it some thought. Thanks for sharing your ideas!

    • Modifié

    It's easy to have a reference to another bone. It'd also be easy to use the other bone's world transform. Unfortunately using its local transform would require large changes to how the physics constraint works. We wouldn't be able to get it into 4.3.

    Would it be useful if the other bone used for movement used the world transform? Actually I am thinking that may be just as good. You could parent it to the root, so it doesn't move normally, then control its movement how you like.

      YGmang
      Spine的物理模拟跟L2D的摆锤模型物理有本质的区别。
      Spine的物理更像是计算所有变换的影响、更像是力的描述。
      L2D是使用摆锤模型、通过参数触发模拟物理。

      在4.2如果你希望减少全局的影响的话你可以使用变换约束。约束骨骼在根骨骼下。
      在4.3新版本上、你可以使用滑块约束去自定义模拟摆锤的效果。你可以把滑块约束理解成给你一个无限轴的参数给你键值。
      当然、相应的花费调整的时间就更多。我的建议是类似你这种需求你自己K个弹性比依赖物理来得更快。
      物理本身就不是万能的、也不能成为偷懒的捷径。物体的运动规律啥的还是得掌握。你可以权衡一下物理修正和绑定优化的时间和效果与直接键帧的时间和效果。


      (视频滑块约束的应用想法来自玉弓芒)

        Nate 大概了解了,我的需求是让一些部件跟随身体运动的同时,它的物理演算数据来源是指定骨骼的本地变化。这种想法在现有的物理逻辑下无法实现也了解了,期待以后会有类似的功能出现!

        还有就是希望把基于透明度的遮罩提上日程,虽然它可能对性能影响较大,但是对于一些特定效果的制作很有帮助(比如:将阴影限制在下层部件上;高光扫过;一些需要限制在部件内部的纹理变化;),只使用现有的裁剪功能绑定过程可能比较繁琐而且经常做不到完美贴合。
        祝spine越来越好~

        • Nate a répondu à ça.

          YGmang
          艹、拜见玉老师。
          我是看玉老师的教程长大的、我是你的粉丝、呜呜呜教教

          YGmang 这种想法在现有的物理逻辑下无法实现也了解了
          This idea cannot be realized under the existing physical logic

          Are you sure? You can use physics on a bone elsewhere in the hierarchy and copy the transform, eg:

          This way the head physics will not react to the body movement, the physics movement comes from elsewhere.

          It may be awkward to setup an extra bone and transform constraint for every bone where you need this. In that case, the head could be moved so it is a child of the root, not the neck. Next create a transform constraint to make the head look like it is attached to the neck. Now create a physics constraint on the head, but set the constraint order so it is applied before the transform constraint moves it to the neck. Now the character's head physics doesn't react to the movement of the body.

          To control the head physics, rotate/translate/scale the head before the physics constraint is applied. The bone is awkward to modify directly because the transform constraint is controlling the position, you'd have to turn it off, move the bone, and turn it back on. Instead you could create another bone and transform constraint to move the head. The 3 constraints look like:

          The neck-to-head naming means "copy the neck transform to the head". It's a little tricky to name, as you could think about it like "the head moves to the neck". It does indeed, but technically the neck transform is copied to the head to achieve that.

          Here is a project showing this, move the head-physics-control for head physics and note in animations when that bone doesn't move, there are no head physics.
          https://n4te.com/x/2061-spineboy-physics.zip

          We tried having "source" and "target" bones for physics constraint, though still using world transforms. The effect is identical to the above. It was easy to have translation come from the source bone, but rotation and scale required more changes. Currently we are thinking that since transform constraints can be used to achieve the same effect, it is not worth adding a source bone to physics constraint.

          If physics constraint could work on local transforms, a source bone may be more useful. However, I'm not sure that is needed. See what you think about the above, I'm curious if it can be used to solve where you wanted local transform based physics.

            Nate 理解了,感谢