Child Of Constraint issues with parenting

0o00o0oo · February 3, 2023, 8:03pm

Two scenarios:

First setup (3 bones system):

Bone A has a Child Of Constraint targeting Bone B, with an influence of 0.5.
Bone A has a second Child of Constraint targeting Bone C, with an influence of 0.5.
Bone B is parented under Bone C.

This setup allows me to move Bone A partially when I move Bone B. But it also allows me to have both Bones A and B to be completely moved when I move Bone C (as opposed to Bone A only partially moving).

Problem: This system fails apart when I scale or rotate Bone C as Bone A seems to rotate and scale at different rates than Bone B. I’d like Bone C to transform A as if it’s a direct child of it.

Second setup (4 bones system):

Bone A has a Child of Constraint targeting Bone B.
Bone A has a second Child of Constraint target Bone C.
Bones B and C are parented under Bone D.

This setup allows me to control Bone A by transforming either Bone B or C.

Problem: Bone D is meant to be a master bone moving everything together. However, when I move Bone D, Bone A doubles its transformation.

Are there simple solutions to solve the above issues?

Blender file with the above systems:
ChildOf_Issues.blend (862.7 KB)

bandages · February 3, 2023, 9:41pm

There’s some less abstract problem you’re trying to solve here, and it would be better to focus on that concrete problem instead.

I would never use a child-of on anything other than 0 or 1 influence, and I would never use it on anything that was parented. It’s not good for that.

I think you should be able to solve your problems by using additional bones and by using copy transforms constraints instead (which will let you copy transforms from parented things to unparented things, or vice versa.)

There is nothing wrong with using non-deforming bones (or any other kind of mechanism). I think you’re trying to avoid doing that, but you shouldn’t. People use non-deforming bones that because it is the simplest solution to their problem, not because they love complexity.

0o00o0oo · February 4, 2023, 12:44am

I’m not entirely sure what this solution involves. The examples I’ve written out are simplified versions of the problems I’m having in a bigger system.

Particularly, with the first setup, I’m trying to build out a system where multiple bones are effectively parented at varying levels of influence to one bone (and thus all sharing the same pivot point from that bone when it’s moved/rotated). And this setup would all need to move together with a master bone.

It could very well be due to me not having a handle on the constraint, but I can’t think of how I’d use the Copy Transforms Constraint to do that, even with additional bones.
Key issue for me is that Copy Transforms Constraint seems to not take into account the pivot point of the target and just pivots around the owner bone’s pivot instead.

bandages · February 4, 2023, 1:02am

Right now, they’re overly simplified, and you’d get better advice from talking about the actual problem. That’s what I’m saying. Because the actual best solution to the real problem may not involve a child-of constraint at all.

Make a bone. Leave it unparented. Give it a child-of constraint. Give another bone a copy transforms constraint targeting that bone, on world-world. Now, the parentage of the deforming bone doesn’t matter.

Do not use “connected” bones. I can’t think of any cases off-hand where they’re necessary, even though Blender makes them by default in plenty of cases.

“Copy Transforms” on world->world acquires rotation, position, and scale of the target. If that’s not working for you, with bones without “connected”, then something else is going on, and I could explain it only given a file.

Here I am copying transforms, rest and pose:

We don’t acquire the pivot point of the bone; we acquire the literal transform of the bone, which has that pivot point built in, because the target bone has been transformed around that pivot by its parent.

0o00o0oo · February 4, 2023, 10:01am

I’m not clear on how that solves anything. For instance, if I implement what I’m understanding:

Bone A has a Child Of targeting Bone B, with an influence of 0.5.
Bone C gets the Copy Transforms targeting Bone A with World/World, so it snaps to where Bone A is.

^This is what you’re describing, correct? Then doesn’t Bone C just behave exactly like the problematic Bone A?

Here’s a stripped down version of the rig:
RigExtract.blend (1.3 MB)

There should be a bone that’s selected when you open up the file.

Try moving that around and you’ll see 5 bones follow at varying levels of influence using Child Of Constraints. And obviously, you can rotate/scale as well.

But select and transform the “Head” bone in the back and this is expectedly where the problem shows itself.

I’ve since changed up the system to use various Copy Location and Transformation constraints to replicate a similar behavior, but this was a tedious process, and even then, arguably not quite as organic as using the Child Of constraints. I would love to not have done this work around.

What would be your solution?

joseph · February 4, 2023, 1:30pm

You are definitely an expert, so I fully believe this, but I’ve never heard this advice before and I’m curious what the rationale behind it is. Is it just about getting that literal transform instead of the pivot point? I’m struggling to understand why that’s better, in my head you’re saying to treat bones like empties that don’t have “length”, is that right? Sorry if this is off-topic, @0o00o0oo if you want I’ll remove this and DM bandages instead

bandages · February 4, 2023, 3:39pm

I’m not saying anything about tails (it’s still good, for purposes of autoweights, to put the tails of bones at the same location as the heads of their children.) I’m talking about the literal “connected” property, in properties/bones/relations. If a bone has the connected property enabled, it can rotate or scale, but it can’t move-- it will be locked to the location of its parent’s tail. That will make it so some constraints won’t work properly (like, for example, a copy transforms.) If somebody is having trouble getting a constraint to work, a constraint that involves moving bones, that’s one of the things I’ll tell them to do, because I don’t know if they know about that trait or what it means.

bandages · February 4, 2023, 4:05pm

I think the main problem here is that you expect that a child-of replaces their inherited transform. It does not; it acts on top of it (and on top of any other transforms it gets directly from transform fields, or indirectly, from constraints evaluated earlier than the child-of.)

This means that a child-of can easily lead to doubled-up transforms; that’s why I said I never use a child-of on a parented bone. (Well, “never” is always a risky thing to say, there are probably some weird situations where I do, but generally speaking.)

Make Bone D. Leave it unparented. Give it a child-of targeting Bone B at full influence. Give Bone A a copy constraints targeting Bone D at reduced influence.

This is different than giving Bone A a child-of directly, because the child-of acts after other parenting. Bone D will be unaffected by parenting, because it has no parent; it won’t get any doubled transforms. Because A copies constraints, that replaces its own parenting rather than acting on top of it.

So if I get this right, the real problem here is rigging an eye, is that correct? In particular, trying to get several controls to act reasonably from a single control.

Here are some other options:

One way to handle it is with spline IK:

Another option is to control them by parenting them to a stretch-to bone:

I’m not sure if your intention is that the eye controls’ rotations matter, or if the damped track bones are literally the deforming bones. If rotation doesn’t matter, there’s no need to use child-of; you can simplify things by just using copy location bones.

If rotation does matter, a better way to control it is by making a locked track marker: