[Closed] constrain pos to a spherical radius

it’s the default behavior for bones. just be sure that both boneEnable and boneFreezeLength properties are set to ON

That was my first approach, but CTRL is for animators, so it needs to be work reliably with auto-key.
Bone Ends do not auto-key : they auto-key their parent bone’s controllers instead.

You can set a key on a bone end with the set key button,
but this is not what the animators want.

is there some way to let bone ends autokey?

Key frames on bones are not what is needed.
We store our animation data on as control object key frame data, not bone key frame data.
I need the process to produce keyframe data on CTRL.pos.

What would happen if the CTRL object isn’t constrained to the radius of the bone’s length? Would that result in squashing/stretching of the bone in the engine?

Could you try path constraining a dummy to a circle whose radius == bone’s length. Look-at constrain the bone to the dummy then wire a CTRL object’s Z_pos to the dummy’s path percentage and the CTRL’s Y_pos to the circle’s Z_rot? Or would that not work because the keys are on a “joystick” type CTRL object?

constraining the CTRL like a bone nub was a specific request of the animators.
This is for a facial bone control rig, and they want the CTRL objects to more or less adhere to the face. Free floating CTRL objects have less predictable results : the farther form the mesh they go the less predictable the bone’s rotation – and thus mesh deformation – will be.

an example of the style of face bones (not mine)

The CTRL objects need to move in all dimensions,but stick to the bone radius. I don;t think a circle path would give the animators what they want.

As it is, the Bone enabled set up works 90%.
that last 10% is the auto-key ignoring CTRL.pos and setting bone.rot keys instead.
The animators could set key deliberately, but they don’t want to by force of habit.
Maybe I need to script something that forces set key on any child of those bones…

wow… can’t say anything else. do you really want to implement this UI approach? today… it’s might be a fun but too ‘vintage’ …IMHO

I may have found something

when transform $CTRL change handleAt:#redrawViews  do (
	if (animButtonState) then(
		addNewKey $CTRL.controller[#Position][#Zero_Pos_XYZ] currentTime
		)
	)

So it looks like I can cause the desired behaiviour via change handlers…but these are not saved with the scene. Can I Put change handlers into a scripted custom attribute?

It may be a bit ‘vintage’ but we have a very low target platform, so exportable bones and such are limited. Given the need for the CTRL key data to be separate and the bones to not stretch,
what would you recommend? I don;t think I have the bandwidth for a full on OSIPA style face rig…

you can save “when” change handlers in the scene by assigning it to a persistent global variable. But this will fire and put a key on every frame. Look at one of my threads where I’m asking questions about “when” handlers, where Denis explained they’re not good for animation.

Just link your control object to your main bone (not the nub) and turn on its bone property then your dummy or point helper will move like you want (in essence it acts like a nub bone now); to avoid keying the parent bone… try this:

on your CTRL object disinherit rotations from parent bone. Then wire your CTRL object rotations to your parent bone rotations and make it a two-way connection. Then set your coordsys to parent and animate your control object’s rotations… then have a callback or something to go back and put a position key at each frame where you have a rotation key on your control object.

seems to work for me in a quick and dirty test. Not sure what the drawbacks might be. Anybody see any pitfalls with this idea?