Loopy parenting issue with controllers

#1

My controllers (yellow shapes and arrows in the picture) are in a “Controllers” group in the Outliner, separate from the “Geometry” group, as is considered best practice. However, some of the controllers must move with the geometry. For example, the wheel swivel and rotate controllers must follow the wheel as the landing gear collapses. I tried to use a parent constraint, but it seems to cause problems, because the wheel is already constrained to the controller. This creates loopy logic where the geometry is constrained to the controller, and the group the controller is in is constrained to geometry. It causes weird behavior. How can I constrain the controllers to the geometry when the geometry is constrained to the controllers?? Thanks for your help.

#2

you should instead constrain the controller’s group to the geo’s parent’s influence.

so separate hierachies cover this.

FK1_ctrl -> FK2_ctrl_group -> FK2_ctrl
     |                           |
Wheel Arm         ->           Wheel Geo
    Geo

this avoids those cyclic errors.

EDIT: formatting

#3

I didn’t understand your diagram, I am sorry. Here I include a snapshot of my Outliner, including the constraints I placed on the geometry and on the controller. The geometry is named swivelJoint and the controller is CTRL_rearWheelSwivel. You can see how they are parent constrained to each other. Could you please explain how I should change it? Thank you for your effort.

#4

You’re controllers should have the same hierachy and spatial placement than your geo. (create controllers at 0 0 0 of each piece w/ the same orientation, and parent them accordingly), then it’s all a matter of parent constraint all controllers to the geo(and scale if you want to be clean). This in turns mean that your geo doesn’t need to be in a hierachy, all elements could be in a single group. In production i find it’s actually rare to parent geometry to geometry.

#5

Sorry, not sure I understand. Do you mean that the hierarchical structure of my controllers in the Outliner should look identical to the hierarchy of the geometry? What do you mean by “create controllers at 0 0 0 of each piece”, are you talking about the pivot point or the origin? I’m using Maya, not 3D Studio Max. Some of the things you spoke about are unclear to me. Are all my controllers supposed to have their pivot at 0 0 0 ? Also, if my geometry is not supposed to be in a hierarchy, how do you attach it together? Using constraints? For example, I think the wheel should be a child of the strut, and so on, but if there is no hierarchy, what makes the wheel move when the landing gear collapses? I think it would be easier to see a snapshot of a sample Outliner with the correct structur[size=2]e.[/size] I read the answer several times, but I still don’t understand.

#6

Take a look at this scene and see if it helps (Maya 2013).

On the global ctrl I’ve put an attribute to control the landing gear folding. This drives groups above the actual controls you grab and interact with. You could alternatively control those groups with something else, other nurbs curves, whatever.

#7

People probably have different approaches when it comes to hard deformations; but I like to keep my geo in groups that have little to do with hierachy (but that will be helpful for layers, and shading, for instance to add matte groups)

In my case the ‘brain’ is in the controls group (I didn’t put any fancy aim constraint/ scIks etc… but you get the idea). I like to put ‘zero’ groups above my controllers so that instead of freeze transforming everything I still have worldspace info (and my controllers are still at 0).

The main reason I do this is because of unwanted shearing (if you have a geo hierachy and change the scale of parent geo non-uniformely, you’ll have f’ed up rotations & transforms in the children)

#8

Thanks guys for your replies and for the Maya scene and screen shot. It helps a lot!
I have a couple more questions for you…

@royg: I had some warnings when opening your scene because I still use Maya 2012 and I don’t have vray, but that shouldn’t matter. I cannot see the geometry in the scene, but I can see it in the Outliner and based on where you placed the joints and controllers, I can see it looks similar to mine. My question is whether it’s possible / practical to do this without using joints. Since it’s just mechanical transformations, couldn’t I just use geo and ctrls, and put the constraints on the controllers instead of on the joints?

@BernieBernie: In your Outliner, the groups holding the controllers are named “_zeroout”. Is it because the groups have frozen transformations but the controllers don’t? Is that how you avoid the shearing problem you described before?

Thank you again for your answers!

#9

Strange about the geo not showing up…

Anyway, you totally could use constraints instead of skinning - I just have a habit of skinning everything (even if it’s only to one joint) for point caching.

#10

no shearing happens when you have non uniformly scaled parents.

I use zero-out groups because I’m not fond of freeze transformation as you ‘lose’ infos, but that’s just me (ie if you rotate an object in the world, and freeze transform it, you have to go through hoops to find its worldspace rotation value). It’s a rigging habit mostly; I also use these groups for other purposes.

One thing which I mentioned above and find a little annoying when using geo hierachy is that if you want to have a renderlayer with only the bit above the wheel (its parent); you’re screwed.

Again, I do all this because when you have a pipeline, tools, asset managers and what nots you have to be clean and thorough. But for personal stuff I’m quick and dirty, but I’m aware of what might screw up when I do this.

#11

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.