Maya Slug Creature Rig

Rigging
#1

I’m sure this an eternal rigging problem with no solution outside of writing your own nodes but if it has been asked on here before I can’t find a thread.

I’m working on rigging a slug creature and looking into setting up 4 joint chains for the “spine”, each with a different root (front end, mid-front, mid-back, back) to allow for movement like raising and turning with the ability to switch to a new root-oriented setup depending on the motion required. I’m familiar with space-switching and FK/IK switches so I was thinking that by creating multiple chains and parenting these to a single master joint chain, I can switch between the functionality using a custom attribute.

This raises the question of the best way to keep this functional. Say the animator was working on a raise and dive attack animation. By switching the space to another joint chain, the geometry would go back to the default pose unless this position was either set before space switching, a la FK/IK switch setups.

Is there a better solution for rigging this to allow for switching functionality without losing current keyframes? I wondered about using some kind of parent constraint setup to move all of the controllers together at once, thus keeping the keyframes when the space was switched, but this creates evaluation errors and is just a pain to work with.

Hopefully this all makes some semblance of sense and looking forward to hearing what ideas are out there. Also if there are any recommendations as to other solutions I’d love to hear them. Thanks all!

#2

what you are talking about is a dynamic parent constraint, its basically the same as a spaceswitch but has some extra functionality to keep the worldspace coordinates after switching. htis can be done easily in a scriptjob/expression

2 Likes
#3

With space switching there’s really 3 trains of thought:

  1. The objects local space and keys get transformed through the switch - the offset lives with the control and you can see the changes in the f-curve. Great for animation as they can see the physical change in values.

  2. The objects parent space gets keyed/transform with an offset - (E.g. a group with a control under it) - this is cool as the controls keys are not changed, it all happens on the parent/group space.

  3. The parent space get transformed to the world space of the target, but the offset is keyed in the constraint - similar to 2, but the offset is yet further abstracted away.

These all have consequences - hiding the offset in a group, means the mechanic is hidden away from the animator. When issues arise it can be hard to debug especially when the mechanic is a seamless switch - you have to do transform inversion and resolve all the switches along the timeline resolving any key shifts. Your basically spending 20% on the mechanic and 80% on tools to make the system working and clean itself up if need be.

Having the offset purely on the control (what I do) means the artists clearly see the change - but this can break their animation flow - there’s pops in frame values (regardless of it being seamless). But gives them complete control - they’ll tend to do the switching on a layer or set it as a precedent at the start of the animation for the shot/scene.

One thing to be aware is the structure of the space may impact more than the transform it was targeted. An example of this is that you put the switch on a rotation on the parent space, which inadvertently changes the translation of the child’s world space position. So now your keying both rotation and position.

The question you need to ask is what is the core motion the character needs to do at a fundamental level and if that mechanic/controls has what I call a “singular meaning” to the animator - i.e. it only does one thing and its read as only doing one thing. There are edge-cases to this - ik/fk - but you could argue their dynamics are different and do have visible differences.

Layers of spine systems, fk, ik, reverse, pivot, noodle when combined will have the issue of drift and you may get overlapping mechanics that cause counter-rotation (the nemesis to animators).

What Ive generally found is that rig state tends to get set at the onset of the animation. Where as dynamism - motion that has an inherit change uses graphical tools, baking, key able pivots etc…

Expressions btw - as of 2016 I think are flagged as thread unsafe and Maya will wait for them to be evaluated before anything else including skin clusters, evaluation clusters (constraints) etc…

2 Likes
#4

So I’ve been looking into dynamic pivots and from the free example tutorials I could find online it seems as though the theory is there but in practicality it prevents the setting of keyframes. I’ve practised with setting up a box rig and getting it to roll using a script to transfer channel values to a group which is connected to the main controller (mainController -> rotPivotGroup -> rotPivotController), but i’m running into a lot of problems when resetting values for consecutive rolls after the first. I am setting the rotation pivot on the mainController directly so maybe that’s the problem? Any ideas would be very much appreciated.

Currently I’m going to be the only animator using this rig so i’m not as fussed about hiding mechanics. I’ve seen a few snake rigs that use sine controls to create motion but they rely on a purely visual aspect, whereas i’d like to preserve joint location for export to UE4. Ideally i’d like to create a multifaceted rig but perhaps it would be easier to split it over two instead.

#5

I’m only replying about what you said about sine deformers.

If you want to use non-linear deformers or other effects, then you can deform a motion path or ribbon or equivalent instead of deforming the geometry directly. Attach nodes to that ribbon. Constrain your clean game skeleton to those nodes. Then you can bake the constraints and export to the game engine.