Offset groups for controllers
Hi there fellow riggers, Just a curious questions, to your preferences, what is the max or highest number of offset groups would you prefer to have on a controller?
I am currently studying on python scripting(with somewhat basic knowledge of mel) and to be honest, i wasnt that pleased with rigbox_reborn script as it only provides with 2 offset group to begin(BUT its STILL a great tool to have!). So I am using this chance to create my own rigging tool to enhance my workflow + do python (hands on).
I personally likes to have 4-5 offset grps on my controllers. -cheers!
Happened upon this while I was in the middle of trying to decide this very question for my own autorig. I'd be interested to hear what other people do. So far, I normally go: ctrlName_BUF (locked buffer group to hold trash values) ctrlName_CONST (constraint group for built-in spaceswitch or constraint inputs ctrlName_EXTRA (for further control or animator-made constraints) ctrlName_CTRL ctrlName_PIV (if you have a parent/point constraint from the control object to another node, any changes to the pivot point will also affect the position of the constrained node. This lets you keep pivot behavior, as well as letting you more easily add post-ctrl offsets if necessary)
I used to keep the buffer group so that if I deleted my constraints when the rig wasn't quite at bindPose, i'd be able to tell that it was off and easily correct it. But I think you could easily store the base values for the buffer group in a custom float3 attribute on the constraint group, so you could drop that one pretty easily and not lose anything. You can also conceivably drop the extra group in favor of using animation layers, which would probably actually be more predictable (for instance, scaling the 'extra' group will cause the control to move away from the 'extra' groups center, if it has an offset translation value. Which I think might not happen with animation layers? Then again I've known some animators that never implemented animation layers in their workflow, so layered groups might be more comfortable for them)
I created a python module that is specific to this problem.
This is how I use it.
import control. Control as ctrl
left_arm_footIK_ctrl = ctrl("left_arm_footIK", shape=A set of points for the cv position, scale=1.0)
this will create 1 control curve and 1 offset/buffer.
then I can do the following:
left_arm_footIK_ctrl.add_layer()
left_arm_footIK_ctrl.add_layer()
the i will have :
offset
then I can access the transform nodes using
left_arm_footIK_ctrl.offset #the offset
left_arm_footIK_ctrl.ctrl #the control
left_arm_footIK_ctrl.layer0
left_arm_footIK_ctrl.layer1
I will share the codes if you are interested :D
@denilson020898 forgive my tiny brain but I dont really understand the concept behind your code. :O Does this create a actual null on top of the ctrl or ? I dont really get the "buffer" thingy too. Please forgive my limited knowledge but i am really interested to learn more XD
Hi! I personally use as less as possible. Most of the time I have one group above the control, as I don't need more. The only occasions where I would need more is if I have anything else that needs to affect that control. Say for example, having pre-built poses for the fingers would need an extra offset, so you can work from a zeroed out transform.
Other cases would be if I need to negate any transformation happening above the control I can use another transform to do that.
I am curious, what do you usually use the 4-5 groups for?
I will have them as for etc 1.L_ikctrl_offset grp (as you know, offset = offset) 2.L_ikctrl_holder grp (incoming connections) 3.L_ikctrl_SDK grp(well, set driven keys..) 4.L_ikctrl_constraint grp(for animators in case they need to constraint to) 5.L_ikctrl_grp(a sub grp just incase for anything else if the grps on top is fulled)
Only for those impt ctrls i would do my per normal 5 grps above. If not, two is my average(etc IKFK switch.) Hope it helps XD
IMO you want controls with a singular meaning and ones that aren’t counter intuitive to others i.e causing negation of space etc. You can end up with messy issues as users may break a mechanic simply by using the wrong level. Compounded with the fact that you want animation coherence and muscle memory to form when animators move between rigs or hand them off between each other.
I tend to have a control and a parent group acting as it’s basis. If I need to do anything specific - extra groups etc, I’ll make systems just for it and bolt it on where nessecary.