Thank you!

Hello,
I think a useful option for path constraint spacing would be 'proportional percent'. The spacing slider dragged in the editor would have a value of 1 correspond to 1/average-bone-length. Each bone would then be spaced along the path according to the slider setting multiplied by its own length. Thus each bone would be spaced slider-value*bone-length/average-bone-length along the path.

This would allow you to have non-uniform but proportionally-constant spacing.

I ran into the need for this when trying to make a setup for controlling armadillo body 'sections' with a path.

Yeah it'd be handy if reordering got turned on for transform constraints. Good to know it already works for path constraints though.

I guess ctrl + click would be more consistent, sounds good.

And thanks for the tip!

Thanks for the response. Having to key all those constraint mix changes is what I'm trying to avoid, though, so I'm looking into using IKs. Is there any way to make sure the distance between an IK target and tit constrains remains constant?
Like this, but where there distance between the two bones is constant:Rotate about either end of bone IK.spine

Hello,
I'm wondering if there's a way to set up a bone so that it can effectively be rotated about either of two points, in my case with the points being the origin and tip of the bone.
This does it, but poorly: Rotate about either end of bone.spineI need to be able to do this without having to constantly adjust the mixes on transforms from 0 to 100 and back, as I'll have fourteen of these making up the main portion of a character's body.
Any ideas?

I've just been doing my first rig that has lots of bones constraint by the same transform constraint, and found something I hadn't realized: the order in which you select the bones to be constrained matters (makes sense now that I think about it, for the same reason order of constraints matters).

However I was disappointed to find that you only seem to be able to change this order by starting from scratch and re-selecting each constrained bone in the order you want. Since Spine already has the nice pop-up vertical list of constrained bones when you click on the abbreviated horizontal list, why not just let users drag to reorder in that menu?
This would be somewhat similar to how you can change the draw order of bones that are bound to a mesh.

Also one more improvement for selecting which bones are constrained: after clicking the little 'pencil' 'edit' icon to initiate choosing bones, holding shift could add new bones instead of starting from an empty list. Or instead you could hold shift as you click the 'pencil' 'edit' icon.

Ok, great, I'm glad I was able to communicate why this could be useful. I'd also be interested to hear about other cases where this feature could significantly simplify a rig.

Anyone reading this have an example?

I know I can move the hold bones or make more constraints, but I'm suggesting a feature that would make that unnecessary.

The octopus example would be extremely cumbersome to make with methods you suggested. I know it's a silly example, but I think the issue of wanting to change which bones are constrained by a transform constraint is not uncommon.

Perhaps this will be a better example:
I'm making a dodgeball animation, in which my character has different kinds of balls flying towards them and they need to catch each ball and throw it back. There's a basketball, a baseball, a softball, a tennisball, a golfball, and a bowling ball (6 different balls).

With the way Spine works now, I would have to have one transform constraint for each ball. If I had a second character, I would have to have another constraint for each ball. If I wanted each character to be able to catch each ball with either their left or right hand, I'd have to have another constraint for each player for each ball. This would mean 6balls * 2characters * 2hands = 24constraints just to make each ball be able to attach to any hand.

If I were able to key which ball(s) was(were) constrained to each hand, I would only need one transform constrain per hand, 4constraints. I would then just key the constrained bone to the bone that corresponded to the ball the character needed to catch at that time. It would also be easy to make the character catch more than one ball at a time by constraining more than one ball at a time. It would even be easy to make the character catch a ball with both hands by making one hand constrained to the other hand.

A similar example is characters that are trying on different hats.

Note that all balls (and all hats) must be visible at one time, so skinning different balls (and hats) is not a solution.

I am.
I've tried downloading both versions of the project uploaded by Erikari that I see, is there another one?

I see that the hands go from not being attached to the weapon to being attached to the weapon, but I don't see where one hand switches from holding the weapon at one position to holding the weapon at the other position.

I want something like the hand-l bone go from being constrained to bone hand-l5 to being constrained to bone hand-l3.

That doesn't show the hands swapping holds.

Really? How would you change which hold the hand was bound to in the animation?

Yes, but I'm trying to avoid having more constraints than I have holds. With the method linked, I would need one constraint for every combination of hands and holds.

This isn't too bad for a humanoid, you only need 4, 2 for each of the two hands to each of the two holds. But say you have and octopus with 8 arms holding a spear at 8 different holds. This would require 8 * 8 = 64 constraints if I wanted to be able to attach any hand to any hold.

I would need more constraints if I wanted a hold to be able to have more than one hand attached to it at the same time. This would lead to 8 * 17 * 8 = 1088 constraints!!

Perhaps, but I'm not familiar with the terminology of parenting when it comes to constraints. If you mean actually re-parenting from one bone to another, no, I'm only talking about pseudo-re-parenting via transform constraints.

Yeah, that's where I started for my animation. Now I want to be able to make each hold-bones+constraint on the weapon be usable for either (or both) hand(s) by changing which hand(s) is(are) constrained by the transform constraints that target the hold-bones.

Just to clarify, I'm not talking about actual re-parenting, I'm just talking about transform-constraining bone-c to bone-p with no offsets and 100% mix to simulate re-parenting

Lately I've found myself creating duplicate transform constraints with the only difference between the two being which bones are constrained.

Say you have a weapon bone with two hand-holds: hilt-hold and pommel-hold. The weapon bone has two zero-length child bones to represent these hold positions, and transform constraints to make a character's hands stay on the hand-holds.

If I want the flexibility of having the character hold the pommel-hold with either their left-hand or right-hand, I have to have two transform constraints: one constraining the left-hand targeting the pommel-hold, one on the right-hand targeting the pommel-hold.

I think there could be a lot of applications where a transform constraint is being used to simulate re-parenting and the spine user could want to be able to change which bone(s) are 're-parented'

The ability to key which bones are constrained would make it so I only ever need one transform constraint for each bone I want to 're-parent' to.

Preview is better than nothing, but it's not the same as being able to manipulate bones directly to check that constraint settings are having the effects you want. I suppose setting up a few test animations to check certain cases constraints might not act properly in could help.

It's probably because I'm still learning about what some of the constraint properties do, but I use a lot of trial and error when setting up my constraints. I'll set constraint properties one way, drag around the target bone, set the constraint properties another way, etc...

Because it's a pain to have to switch to animate mode to test every time, I end up changing things in setup mode and then undoing the changes I made while testing. I inevitably forget to undo a change that was for testing.

That fixed it, thanks! Can't believe I forgot to check the inherit options...