Joints break constraints?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
  04 April 2013
Joints break constraints?


I'm making a rudimentary hydraulically operated crane, constructed from 3 poly members (like a finger). I can animate it using constraints and everything works fine. The members move as expected, and the hydraulic rams follow the movement of the spars perfectly. (See screenshot)

So I decided to add a little sophistication by using a skeleton system to move the members. I added the joints and rigidly bound them to the spars. The joints behave properly, and the spars follow them just fine. Unfortunately, all my parent constraints which held the ends of the hydraulic rams to the spars appear to have been broken, resulting in floating parts. So I tried constraining the rams to the joints themselves and things got really weird.

I started over with a simple two spar setup just to test, and sure enough, rigging with joints breaks the parenting constraints to the skins.

I admit to being a novice with using joints, but I was surprised by this behavior. Can someone please give me some pointers about using joints in conjunction with constraints?

All help appreciated!

  04 April 2013
If you're doing this for rendering and you're not working in a pipeline with rig requirements then just use whatever works to get the job done.

Ideally, you want to have the joints driving the geometry, and a set of controls driving the joints through constraints. Using nodes like empty groups can greatly benefit the flexibility of your rig. For instance, you can have a joint orient constrained to a control, then driving elements of the hydraulics can be children of that control. When you're using controls (you can make them your self out of cv curves) they should have their pivots set to that of the joint they are effecting. Empy child group nodes can have their pivots anywhere, but usually the same pivot as the parent. The resulting system means the children of a control will inherit the movement of your control, but can have their own transformations.

Also, you can create empty groups that are parents of your controls, that way you can create set driven keys or constraints on them to create movement, and then have added control manually with the control. To give you an example, I recently set driven keys on parent groups of the fk controls of a mechanical character. That way I could create a standard mechanical transformation animation driven by a custom attribute on my characters main controller. This way my controls move with my sdk animation, and allow for their own transformations under the parent with sdk.

I'm not a rigger by trade but I've always tried to rig my own characters. A couple pieces of advice:

1. Always make sure your control transforms and rotations are zeroed out before connecting them to a rig hierarchy. Getting back to a bind pose is essential.

2. I can't stress this one enough, make sure everything you use in a rig, whether it's bones or controls or empty groups all share the same orientation before integrating into a rig system. This will save you a massive amount of time and a huge headache.

3. Name everything always. Use a prefix to denote what side of the character, Left or Right for both controls and joints. Created constraints can inherit these names. The more complex your rig gets it's easier to tell what your looking at, and if you can guess what something is named you can select it much easier either by using Mel or the outliner filter.

4. Get used to looking at your outliner, with unselected invisible group nodes you'll only be able to see them and what their connected to in the outliner or hypershade or hypergraph.

Hope this helps.

Last edited by jgibz : 04 April 2013 at 09:24 PM.
  04 April 2013
Many thanks for your thoughtful and detailed response, jgibz. Very helpful!

No, I don't work in a pipeline. Which is both good and bad. Good because of the lack of pressure. Bad because of the lack of discipline, particularly in the areas you mention.

However, I believe I found the solution by creating a simple two-spar system and rigging it. The "hydraulic cylinder" is a self-contained system built of two cylinders, two rings, and a couple of point and aim constraints I copped from a YouTube tut by a guy named John Parks. The secret in my case was to parent the two end-rings, respectively, to the two bones that comprise the IK chain that I built to animate the spars, as opposed to trying to connect them to the spars themselves. Works just like it should. I then transferred this strategy into the real scene, and it too behaves politely, although it did point up the need to retool the geometry.

Thanks once again!

  04 April 2013
Good to know you got it working.
  04 April 2013
Thread automatically closed

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.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 04:43 AM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.