Jamez0r

  • 13 дек 2024
  • Регистрация: 26 мар 2016
    • Изменено

    @Pentacles FYI: We have just pushed a commit to the 4.2-beta branch which replaces the ApplyTranslationToPhysics and ApplyRotationToPhysics bool properties (and their Inspector counterparts Transform Translation and Transform Rotation) with Vector2 and float scale-factor properties. This covers disabling the feature by setting the factors to 0.

    A new spine-unity 4.2-beta unitypackage is available for download as well:
    https://esotericsoftware.com/spine-unity-download#spine-unity-4.2-beta

    From the changelog:

    PhysicsConstraints: bool properties ApplyTranslationToPhysics and ApplyRotationToPhysics were changed to Vector2 PhysicsPositionInheritanceFactor and float PhysicsRotationInheritanceFactor to allow the Transform movement the be scaled by a factor before being applied to the skeleton. You can set the properties to Vector2.zero and 0 respectively to disable applying any Transform movement at all. The Advanced Inspector section Physics Constraints was renamed to Physics Inheritance, the properties in the section are now called Position and Rotation.

    PhysicsConstraints: Skeleton GameObjects now automatically apply Transform translation and rotation to the skeleton's PhysicsConstraints. You can disable applying translation or rotation at the Skeleton component Inspector under Advanced - Physics Inheritance by setting Position to (0,0)and Rotation to 0, or by setting the properties physicsPositionInheritanceFactor to Vector2.zero and physicsRotationInheritanceFactor to 0 at the skeleton component via code.

    I would recommend you to back up your current project and update early if possible, since the property changes are breaking changes. In other words, you need to re-configure any of your custom Transform Physics Inheritance settings (either disabled or using a strength modifier other than 1), since the old bool parameter no longer exists and your own parameter is likely named differently. And it's better to do it early than late where you might then need to re-do more configuration work.

    If you want to migrate your own strength modifier parameter, you can add
    [UnityEngine.Serialization.FormerlySerializedAs("yourTranslationModifierVariableName")]
    before the line
    [SerializeField] protected Vector2 physicsPositionInheritanceFactor = Vector2.one;
    in SkeletonRenderer.cs and the same for physicsRotationInheritanceFactor before opening your scenes (or before opening Unity at all). Then you should not loose any of your settings.

    @Jamez0r Pinging you here as well just in case you've already updated to the previous package, so that you can avoid losing any settings as well.

    The documentation page will be updated accordingly very soon as well.
    Hope you like it 🙂.

      @Jamez0r Sounds very cool, looking forward to seeing your wind effects! 😎 👍

      We've just published another commit to 4.2-beta which now also applies Transform rotation to Skeleton PhysicsConstraints.

      Applying Transform movement is enabled by default for both translation and rotation.
      You can now disable applying translation or rotation by setting skeletonRenderer.applyTranslationToPhysics or .applyRotationToPhysics to false via code. These attributes will likely be exposed in the Inspector in the future as well.

      @Jamez0r No hurry at all. Actually it's good to hear that you've not tested it yet, as we also just discovered and fixed a bug where Transform Z movement instead of Y movement was used, ignoring vertical movement in most cases.

      A new spine-unity 4.2-beta unitypackage is available for download here as usual:
      https://esotericsoftware.com/spine-unity-download

      • Jamez0r ответили на это сообщение.

        Harald Please note that this does not yet include automatically applying GameObject movement to Spine's physics yet, this will be added later.

        @Jamez0r We have just pushed a commit which enables applying Transform position changes to skeleton physics.

        A new spine-unity 4.2 unitypackage is available for download:
        https://esotericsoftware.com/spine-unity-download

        • Jamez0r ответили на это сообщение.

          @Jamez0r We've just pushed a bugfix to the 4.2-beta branch. A new 4.2-beta unitypackage has just been released:
          https://esotericsoftware.com/spine-unity-download
          We hope that this now fixes all issues you encountered with 4.2-beta 8). Thanks again for reporting!

          Issue ticket for later reference:
          EsotericSoftware/spine-runtimes2448

          • Jamez0r ответили на это сообщение.

            @Jamez0r Glad to hear the updated fixed your physics-related issues, thanks for the feedback!

            Sorry to hear that another issue remains, thanks for the reproduction project. We'll have a look at it and get back to you here on the forum as always. Thanks for reporting!

            @Jamez0r We have just pushed a bugfix to the 4.2-beta repo, it turned out that load scale (import scale in Unity) was ignored, affecting wind and gravity. A new spine-unity 4.2-beta unitypackage is available for download:
            https://esotericsoftware.com/spine-unity-download
            Please let us know if this now fixes the issues on your end as well. Thanks again for reporting!

            Issue ticket for later reference:
            EsotericSoftware/spine-runtimes2446

            • Jamez0r ответили на это сообщение.

              @Jamez0r Thought you might be interested in the above 4.2-beta update, since you've perhaps integrated similar MeshGenerator.cs changes in your local spine-unity installation. 🙂

                @Jamez0r We have just pushed integration commits of 4.2-beta physics and 4.2-beta skeleton loading to the repository for spine-csharp and spine-unity. Please note that this does not yet include automatically applying GameObject movement to Spine's physics yet, this will be added later. Nevertheless, you should now be able to import and play back your PhysicsConstraint-driven 4.2-beta skeletons in Unity. 😎

                New spine-unity 4.2-beta packages are available for download here as usual:
                https://esotericsoftware.com/spine-unity-download#spine-unity-4.2-beta
                Please let us know if you encounter any issues.

                  @Jamez0r Glad to hear, thanks! 🙂 Also looking forward very much to seeing your new project! 😃

                  Thanks for the quick feedback @Jamez0r, glad it's resolved now!

                  Thanks so much for your work and for sharing your code and for your writeup @Jamez0r! Much appreciated, I'm sure it will help!

                  Harald написал

                  I'm afraid to say that the spine-unity runtime does not support updating collider shapes yet. It would anyway be a very bad idea to update the mesh of a PolygonCollider2D at runtime with the animation. Unity has just introduced a new collider type CustomCollider2D in Unity 2021.2+ which would allow updates of colliders at runtime with reasonable performance.

                  User @Jamez0r on the forum once started an implementation, as can be seen on this forum thread:
                  [Discussion] Mutable physics colliders in Unity 2021.2
                  Unfortuantely the thread ends without any results or insights being published yet.

                  In your case we would however strongly recommend to not use a single polygon collider at all, since that's a very computation-heavy solution for the physics engine. Instead it would be much better performance wise to use multiple box colliders. You then typically use BoneFollower components to let them follow the respective bones and adjust the bounding box shape in Unity. Also be aware that gameplay-wise, you will rarely want the collision shapes to exactly match the character for the best user experience. In e.g. beat-em-up games the hit-boxes are typically larger than the character to provide the best game-feel, as can be seen in this forum posting by Nate:
                  Spine - libGDX collision detection

                  Thank you for your reply. It's very helpful to me :grinfake :grinfake

                  I'm afraid to say that the spine-unity runtime does not support updating collider shapes yet. It would anyway be a very bad idea to update the mesh of a PolygonCollider2D at runtime with the animation. Unity has just introduced a new collider type CustomCollider2D in Unity 2021.2+ which would allow updates of colliders at runtime with reasonable performance.

                  User @Jamez0r on the forum once started an implementation, as can be seen on this forum thread:
                  [Discussion] Mutable physics colliders in Unity 2021.2
                  Unfortuantely the thread ends without any results or insights being published yet.

                  In your case we would however strongly recommend to not use a single polygon collider at all, since that's a very computation-heavy solution for the physics engine. Instead it would be much better performance wise to use multiple box colliders. You then typically use BoneFollower components to let them follow the respective bones and adjust the bounding box shape in Unity. Also be aware that gameplay-wise, you will rarely want the collision shapes to exactly match the character for the best user experience. In e.g. beat-em-up games the hit-boxes are typically larger than the character to provide the best game-feel, as can be seen in this forum posting by Nate:
                  Spine - libGDX collision detection

                  @Jamez0r thank you, this fixed my problem!

                  Thanks @Jamez0r for answering!

                  Unfortunately multi-layered SkeletonMecanim blending cannot easily be fixed. For smooth mixing-out you need to ensure that either your higher-layer animation uses a mix-out animation to revert the changes, or that you have keys at your lower (base) layer animations and transition the higher-layer animations to an empty animation. You can find a (very recent) forum posting regarding the same topic here with a few more details:
                  use SkeletonMecanim How to mix layer?

                  Thanks @Jamez0r as always for answering! 🙂

                  @AHAKuo Please note that skeletonMecanim.Initialize(true) comes with quite some overhead, as it re-creates the skeleton hierarchy, re-applies the respective skin, and so on. So we would highly recommend to use any of the two ways suggested by Jamez0r.

                  Thanks for answering @Jamez0r! 8)

                  @[удалено]
                  As Jamez0r mentioned, you can interact with the SkeletonGraphic component just the same as with the SkeletonAnimation component regarding the Skeleton (skins, slots, attachments, and so on) and AnimationState (animation playback) API.

                  Aside from the spine-unity documentation sections mentioned by Jamez0r, you might want to check out the example scenes Spine Examples/Other Examples/Mix and Match, Mix and Match Equip and Mix and Match Skins that are included in the spine-unity unitypackage. While I'm not sure what exactly you are trying to achieve, you will likely find your topic covered in one of these three example scenes.

                  Thanks again for answering @Jamez0r! 8)

                  rudra00 написал

                  but maybe each slot is reading the mesh renderer's layer and is assigned by that? so maybe it could be overriden?

                  Please note that Unity limits sorting functionality here, as each MeshRenderer can have only a single sorting layer assigned. You can work around this limitation by using a SkeletonRenderSeparator component as mentioned above, splitting a single skeleton into multiple MeshRenderers.

                  By default, the spine-unity SkeletonRenderer component just assigns a mesh at its MeshRenderer component, you can then set properties of this MeshRenderer component as desired. There is no additional "sorting layer per slot" logic possible without using multiple MeshRenderers.

                  If you just want to change draw order of slots inside a single skeleton, please see Draw Order in the Spine documentation, as mentioned by Jamez0r above.