Related Discussions
Nate stickied the discussion .

Does this mean we no longer need to use "limiter bones" to adjust rotation of another bone using transform constraints (like in the case of character aiming using IK in a game)?

I want to mess around with this but I don't have time right this instant.

    Daverwob The term 'limiter bones' is not one that we have defined, so I am not sure if I fully understand what you mean by it. However, while it used to be quite tricky to impose restrictions on the range of bone transformations (especially for those that cannot be controlled by IK, such as rotation), there is no doubt that the 4.3-beta has made it much easier to set up. The beta phase is expected to continue for a while, so we would appreciate it if you could try it out whenever it's convenient for you!

        Misaki thanks Misaki, very exciting update.

        In this GIF you can see the aiming IK being moved, and there are 2 green "limiter" bones pointing to the player aiming IK.

        The main yellow "weapon" bones have their own transform constraint targeting the green limiter bones, but with a percentage of the green bone rotation being applied to the yellow bone rotation.

        Ideally one would point the main yellow bones straight to the player aiming IK, but it's tricky as the aiming IK doesn't actually rotate itself, just move X and Y.

        Using the new transform constraints is there a way to skip the green bone altogether? It would be nice as it adds an extra step to the rig.

        Apologies if this is not the place to discuss in detail.

            Daverwob Hmmm, maybe it won't work perfectly in your case because even the new transform constraint doesn't allow you to control a transform from two different transforms like TranslateX and TranslateY, but you can set it up like this:

            In this example, the rotation of two bones (Weapon_R/Weapon_L) is constrained by the Translate X of the source bone (Target). The constrained bones have the Clamp option enabled and the rotation angle is constrained from 0 to 90 degrees. The referenced Translate X is between 0 and 600, so the rotation will only change if the source bone is somewhere between Translate X:0 and 600.
            The reason I said it might not work perfectly in your case is that this rig does not respond to changes in Translate Y. I tried to create another transform constraint and constrain it to Translate Y as well, but it was difficult to make the Weapon_L/R bones always point toward the source bone, so it might be a good idea to create IK constraints and constrain the IK target bones to move within a certain range with a transform constraint.

              {image}
              I cannot properly launch 4.3 on Windows 11 Home 23H2. Happily I have launch window on begginig so I can easily go back to ealier version of Spine 😉

              I can click only on News there.

              • Nate replied to this.

                mirabel Sorry about that! We've fixed it in 4.3.12-beta, available soon.

                  Fantasmic! The new constraints interface is going to take some getting used to, but seems so strong. I know there are things I have done to try to replicate this exact functionality (ie trying to convert rotation to scale or translate etc) for complex (non game) rigs, but it never quite worked. Often having to nest constraints and bone constructs and IKS to get close. Which sucks when you have to also order the constraints as well!

                  Translating X Y etc directly into rotation or scale with clamps and multipliers is HUGELY useful for subtle rigging controllers.
                  I'll have to relearn what how the local/additive checks work, and offset has now been folded into the grid for the non 'Translate' properties.

                  I am assuming the left columns are input min and input max, and map to the right columns output min and output max, and the percentage in the middle is just the rate that gets the sides to match? I notice that changing the percentage manually gives unexpected changes so it seems to be more of an 'averaged result' than an actual lever to fiddle with.

                  inputMin (1st left column) --- maps to ---> outputMin (1st right column)
                  inputMax (2nd left column) --- maps to ---> outputMax (2nd right column)

                  Clamp is for the bones you want to change to not go beyond their min or max outputs?
                  Still trying to wrap my head around local on each side and additive! I think additive is more intuitive than relative though!

                  Awesome stuff.