talk.bindpose.com has been shut down on the 6th of March 2021. You can read a bit more about it here.

You are currently reading an archived copy of the latest content, with all the usernames deleted.

Offset groups for controllers

by user76 posted 22-11-2017 | 6 comments

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!

 

by user36 posted 23-11-2017

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)

 

by user9 posted 23-11-2017

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

layer0

    layer1

        the actual control

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

 

by user76 posted 29-11-2017

@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

 

by user3 posted 22-11-2017

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?

 

by user76 posted 22-11-2017

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

 

by user113 posted 03-01-2018

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.