Dinovan Rig – Progress at 09/11/2016

I’ve got the rig nearly finished now. Gave it to Michael and another classmate and they caught a few issues I hadn’t seen, as well as suggesting a few extra features that were missing.

I’ve added sliding FK controls to the neck (also known as the Trunk rig, developed by Jeff Brodsky), and duplicated the neck controls for the tail. The sliding FK gives animators a reliable method to add arcs at any point to the neck/tail, which gives them just that much more control.
Basically the main neck control (which has the aim-based IK and an overall rotation) is for broad strokes, and the sliding FK controls are intended for finer movements, or to get poses that the broader motions won’t easily allow.

It’s a bit hard to accurately describe how the controls work, and stills won’t really do it either, so I’m planning on making a short showcasing video once I’m 100% finished.

I am sometimes experiencing some random flipping of follicles when the neck and tail are rotated. Apparently it’s an issue that used to happen quite regularly but supposedly it’s been fixed. I’m gonna double check that the connections I added via scripting reflect those created with a manual setup. Failing that, if I’m patient enough, I’ll rebuild the follicles manually. If I’m not that patient, I’ll look into poitOnPoly constraints.

I also want to slide the FK controls up and down the surface using translates; I looked into the parameterDimension tool for that. When created manually, this tool has UV movement tools instead of XYZ. Unfortunately for some reason AutoDesk decided it would be great if nothing could be parented to it, nor could we constrain objects to it.
Great, huh?
I found that I can create the parameterDimension transform pythonically, which lets me parent things to it! Yay! Unforunately, having a child reverts the movement tool to XYZ instead of UV. So that’s a bust. I’ll have to stick to using the position attribute for now.

So, I mentioned in my last post that Michael wants the toes to splay out a bit when the foot rests on the ground. I was going to set up some set driven keys, but then I realised that there’s no reason for me to put that much time and effort into something that gives the animator almost no control.

Instead I slapped an IK handle on each toe at ground level, with a hide-able control for each. I created a ground control for each foot with an offset point constrained on X and Y to the result ankle joint – the ground control now follows the foot around, staying at ground level. If the ground isn’t level, it can be geometry constrained to ground geo, or the animator can manually animate the Y axis.
The IK controls are grouped, and that group is parent constrained to both the result ankle joint and the ground control. On the IK/FK toggle control, there’s an attribute for the foot control. When that attribute is on, the ground controls are visible and the toe ctrl groups are parent constrained to them. When it’s off the ground controls are hidden and the toe ctrl groups are parent constrained to the ankle joint.

This method allows the animator to have an automated toe rest when the foot settles and control how that looks by manipulating the individual toe controls, or to manually animate the toes.

The great thing about this setup is that unlike a bipedal character’s reverse foot, the animator doesn’t have to change their workflow from the reverse foot to an FK driven foot when swapping between IK and FK – it’s all parented under the result joints.

The tail rope has dynamics plugged into it via a blendshape from the nHair dynamic curve to the spline curve. The tail control has an attribute to turn hair dynamics on and off – the same attribute also swaps the driver curve between affecting the dynamics curve or plugging directly into the spline curve. The driver curve is there so that if the animator has a character walking up the stairs (which are on the tail), they can touch and move the rope.

I have a slight issue with the rope system at the moment – if the tail is straight, the rope sits nicely between the loops as shown below on the left. However, if the tail is rotated, some areas of the rope go out of alignment as shown on the right. I think adding a stretch system to the joints will address this, but I wasn’t sure how to apply it to just the areas that are affected by joint rotation – as mentioned earlier, there are sliding FK controls at play here, so the tail could be rotated from any point.
tailropeissue
Justin Broom, a friend of mine who is an ATD at Weta Digital, suggested using a condition node that looks for rotation on the joint chain before passing through the stretch multiplier. I’m going to look into plugging the rotation values through a remapValue node to inform the multiply value. I just have to figure out what the most efficient way is to have only nodes ahead of the rotation be affected. A network of condition nodes would be ridiculous, and I don’t want to write my own node. I’m not really sure how, to be honest.
Possibly a condition node before each scale multiplier would work – the condition node would pass the multiplier through if the previous joint has a scale applied. Then I’d just have to bypass that condition node if rotations are applied. It’s not super elegant, but it’s what I have for now.

So far with this project I’ve figured out some neat control systems and learned a lot about getting the technical parts of a rig to work, without skin weights and deformations masking mistakes. I even got a lower leg twist by aiming the lower leg bones (parented to the knees with pivots near the top of the geo) at locators on the ankle bones. I’ve also got some nice little scripts out of the process that I needed along the way (from big sweeps like creating the neck control system to little things like batch renaming without affecting the affixes), most of which will find their way into my rigger script either as integrated functions or just additional utilities, which I’ll be slapping in a menu to be used individually.
Above all, though, I learned a lot about the importance of planning out a rig ahead of time. For example my front leg FK and IK switch snaps slightly, because I had to drag the IK down by 0.1 on Y so the toes were touching the ground. If I’d planned the rig out, I would have placed the geo there before creating the first joint. I could rebuild the legs, but I’m running out of time, and the likelyhood of an animator ever wanting to switch to FK on this rig is really low.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s