Hi Wayne,
Thanks a lot for the course, it's been really helpful so far !
I'm just not quite sure to fully understand the purpose behind the control bones, maybe it's going to be explained later on ?
Basically :
1) Understood about the part where you probably want to give a "simplified" access to animators instead of letting them play with the full structure : is that why you always separate the two notions of bones dedicated to control vs bones that actually build up the structure ?
Are there cases where you actually animate the control bones and you later on realize that you need to adjust the rig so that it better fits the recorded movements on those control bones (potentially modifying the constraints between the control bones and the underlying structure "after the facts") ?
2) I'm not sure to understand why we linked the "Base squash top" the way we did : why not just use parenting to link the "base def out" to the "Base squash top" ? And even if we didn't want to use parenting, can't we add a constraint to force the base def out to follow location and rotation transformations of the Base squash top ?
Because here the setup seems weird to me : if I understand correctly we force via a constraint the top of the bending bone to follow the Base squash top (which incidentally drives the base def out since it's linked to the B-bone) but then rotation of def out might not follow so we adjust it with another constraint ;)
Why not putting both constraints on the same bone (be it base def out or the head of the B-bone if possible ?)
Hi aaolean
There's a few reasons to seperate control bones from def or mch bones. And yes, the main reason is to have only the bones that are to be animated visible for the animator.
You won't really want to change anything 'after the fact' with the underlying structure of the rig, if the animators find something wrong with the rig it will be sent back to the rigger for them to fix, hopefully without breaking any animation that has already been done. The only 'constraint editing' the animator might do would be to add something like a 'child-of' constraint to a control bone For example, if a character jumps onto a skateboard or something, the animator can add a constraint to the control in the animation file and not the original rig file. (The rig is usually linked in to all the animated shots)
2) The Bone_top_squash would be more logical in the way mentioned. I had planned to add some drivers to control the scale_in and scale_out of the def bones so the t.chest could bulge in the middle. However, this took it from a beginner course to a more advanced course in complexity, so I edited that part out, but the initial foundation was left the same. (I think I refer to it somewhere in the video as 'you will see what I'm doing that later' and then you never do haha)
But that is some excellent thinking there. You should be trying to make it as simple and logical as possible.