The End

So with the rig completely working in tests, I thought it wise to show HOW it will function in the pipeline.
The main difference in it's use will be from Guards and the main character Elita (as the guards will have an extra setup that will come in with the mesh).

The video has little subs of what's happening on the left (so fullscreen might help)


20121022 1747 43Sub from Joshua Griffin on Vimeo.



As shown it's a fairly easy process, as the movement is loosely blocked out for the animator, making them concentrate on limb placement, debugging and slight weight adjustments.

However, there is one considerable drawback to this, and that is the animator is almost locked to the mocap performance. The information CAN be deleted quite easily, and 'vanilla' animation created with the rig, but this is one concern in terms of the performance itself, and it's processing from Ipi Soft Studio.

This research has helped me define a stable pipeline from gathering motion capture footage, to processing it and cleaning it for use in the game engine. This should save me quite a few days, and possibly weeks, within my schedule. It has also taught me how to script effectively and I'll be making a lot more use of self made buttons in the future, especially within multiple rigging projects.

The process of learning this scripting and pipeline has been quite fluid and a god-send in terms of saving time. Without this process I would be making adjustments to the actual motion capture, methodically cleaning curves in motionbuilder and maya - something that takes much more time, and also causing quite a bit of havoc when adjusting in maya after using motionbuilder.

With this research and rig setup complete I will now be able to reschedule how much time I have for animating, freeing up considerable time to use in perfecting the movements, camera choices and editing environment textures. There's a lot of work to be done, and this has saved so much.

Then the issues

So this worked initially.

The bake layer kept the mocap from constantly driving (and therefore constantly destroying the physical parenting of the IK and skin controls).

There were, however, two control rigs.
This posed a problem with which to use and when, as they surely couldn't be used in tandem.

Another issue arose when I added foot roll to the IK. This wasn't constrained effectively to the offset rig at all, and really messed up the translation and/or orientation.

So going back through my notes I started to see WHY my earlier method worked.
It was all down to the baking.
I was also over-complicating things.

This video shows the cleaner version of my initial rig setup (also skinned to a character).

Cams from Joshua Griffin on Vimeo.


The movement works, but there's no additional controls other than the feet. They work, but are also in the 'wrong places' and would have to be altered off from the character.


This next video shows the development of this rig.

20121011 1408 38 from Joshua Griffin on Vimeo.


The video shows two control rigs, one for IK and one for FK, each affecting a different skeleton with driven orientation and parenting between the two.
It's quite messy in it's methodology, and possibly quite confusing for the animators.

As I had made this rig from scratch I was quite reluctant to make another from scratch. That is, until I started to think about 'what if it can just use a single rig'.

This is at the point I went through my past notes and started to get the method.
The baking was the key, and it didn't need to span both of the rigs.
If I could script all of the functions in a single shelf button, so that the order of creation was correct, then I could (brace yourself):

• Snap the rig controls to the rig (this means the rig can be in unique placement - meaning multiple characters)
• Create the IK and parent it to the correct folders
• Drive the Groups of the controls by the mocap locators
• Bake these groups
• Drive the skeleton with the controls (that are within the baked groups)

With the baking it's so simple!! No need to even THINK about infinite loops :/ 

There are also shelf buttons to undo this (though one requires a little extra action).

20121011 1412 47 from Joshua Griffin on Vimeo.

I think this is as far as it's going to get in terms of rigging. There will be a few additions - but none that directly address the pipeline between the mocap and the rig. 

Additions will include:

• Facial Rig for the guards
• SDKs for the fingers
• Testing on referencing

That last point allures to me referencing the rig into a clean scene. However, as my scripts are name-based this has a high chance of not working. I Will likely copy the rig (save as a new name) and import the model. I can then later reference in multiple finished characters and control them via the new referenced scene. 

Scripting

The scripting was quite interesting, as I've never done any before.

It, however, was really very simple.
Before making something I wanted repeating I would reset the timeline to 1 and then go ahead and make the item, or make the selections. This would be recorded in the script editor, and it was just a case of copying this, testing, simplifying and slightly editing it to make it all function together.

The functions included:

• snapping groups and controls to a skeleton. 
• This was so that I could edit the position of the skeleton to a different character and still use all of the other functions built. 
• Creating the IK
• I needed to do this so that I could snap the controls and the IK groups into the correct places. I actually had to snap the IK groups for the feet SDKs twice, once initially and the second time after some of the controls were added, as the IK slightly shifted the joint position. 
• Mocap locators to drive the Control Groups
• Baking the Control Groups
• Controls drive the skeleton
• Scale the mocap down, and into the correct position
• This was so that the translation of the hips was correct, as a larger skeleton would use wider translates. (meaning the character would translate twice as far in all directions)
• Drive the Mocap Locators with the Mocap keys

I also had a little fun with making some icons for the buttons, so they'd be understood and the animator could tell them apart.

notes

These were my notes for additions over the last few days (newest first): Need to get the IK feet driving the skin skeleton. Don't give option for FK feet. IK only - need roll and step to function properly. Separate groups for controls (within hip) and parent to controls


 OLD-----------------

 Without baking, the two rigs still function well. The FK works on the skin rig (full body) and the IK works on the IK Rig Either:: Set up a button that hides the IK rig extra controls (once used) OR.. Set up the IK/FK switch to simple hide/reveal the legs of the two rigs (perm hiding all of the IK upper rig)


 OLD----------------

 Perfect actual use rig - control orientation (possible second bake) --if second bake is used - then are the controls for IK rig necessary? Should really have all controls on a single rig used on the skin skeleton. (IK/FK switch?) mocap baked onto control groups. Controls drive IKskeleton. IKSkeleton drives Control Groups on Skin rig. Skin Rig Controls Drive SkinSkeleton. Distinction is for scaling of the translate. should script in the IK/FK for the skin control rig. Move everything to a single command of 'do' and 'undo'.


 OLD------------ --------------------

 Rig notes

 -------------------- for each character skin rig needs translating into position. Control rig for the skin rig needs moving into position. Control rig for skin rig needs to be constrained AFTER this. [script] (not many characters - so only need to do this manually a few times) Import mocap mocap to drive locators [script] **Done

 -------------------- extras -------------------- 

script to disconnect locator constraints [script] **Done (deleting multiple source mocap rigs may result in LOTS of dead constraints being left in the scene) Bake script [script] --------------------------------

Visual

This is more of a visual explanation of what I've done for the pipeline:



MoCap Rig from Joshua Griffin on Vimeo.

Baked Sandwich

So - after all that fuss I made a little note late at night - so I wouldn't forget.


Mocap drives (p) to locators

Locators drive (p) IK handle and Pole vector
Locators drive (p) Control Rig (curves) upper groups

Bake IK group
Bake Control group

Controls constrained to IK
Controls constrained to IK Rig

Ik Rig Constrained to Skin Rig

All rigs must be in the same physical space - no offsetting rigs.
Layer separate rigs and hide.

-----------------------------------

Can build all.

later..
Import mocap to rig scene.
Drive locators with rig.

Script made to bake IK group
Script made to bake Control Rig

voila!

[end of notes]

What this does is sandwich the Control Rig (that drives the IK Rig and IK controls) between two baked rigs (the IK controls and the Control Group).

[trying to explain] This animates the group of controls separately to the mocap - but they imitate the same movements. Within that animated group sits the real controls that pull on the IK rig - which is driven. Meaning that I can key IK changes without disturbing the mocap data.

So with this I plan to build a rig for a character that has the the same bone position/count etc as the mocap rig. This can be translated to fit the character - and will simply mean that retargetting will be much smoother.
I'll even be building ALL of the dependencies into the rig. The only 'piece of the puzzle' that would need adding will be the mocap rig and the baking of the IK and control groups.

What I've done is researched the what the mocap rig is named as when more rigs are present (what its constant namespace is). It stays the same as a BVH - out of IpiSoft or MotionBuilder.
So based on that I've written a small repeat script as a shelf button (nothing fancy AT ALL) that does two things;
1. It matches the correct locators to the joints on the mocap rig and allows itself to be driven.
2. Double clicking the shelf button will both create the locators (all with the correct names) and be driven by the mocap rig.

The next step will be an even simpler script that will select the IK controllers and the Control Rig groups and bake them for the entire timeline.
This is so simple that I'm leaving it until I actually get around to making a rig FOR a character - it's been trialled manually - so I see no point of automating it now - as the start rigs will have to be translated into place of the current character.

What I also plan to do is make another layer of controls that directly affect the motion capture data - just in case it needs manual (and destructive) editing. (My main reason for this was to zero some of the movement from the feet in the Y axis - to keep the feet from jumping and to ground them more. This coupled with the extra IK is really strong.)

In terms of long-term building, I'll only have to build two rigs (roughly), as I only have two character types in the 3rd year project. I'll have many variants of one - but they will essentially have the same polygon make-up.

I feel really proud of this rig setup - it really was quite a headspin getting it working.

Headaches.

Ok, so this is going to get quite complicated.

I'm trying to replicate the control seen on the video link on the last post.
This is getting the motion capture rig (Mo) to drive Locators (L). Those Locators then drive the Skinned Rig (Skin). The Locators would be held in Groups (G) that are driven by a separate IK rig (IK).
Even at this point it doesn't work - as the locators are driven in world space, and thus their groups have absolutely no control as physical parents.
It gets worse.
Ik rig must also be driven by Mo.
This, however I seem to package it (as the images describe), creates an infinite loop.
At best I was able to make it 'work' - though this drove the locators in an additive fashion - making them rotate and translate twice as much as they should.

There were also other solutions - though these created dual dependencies and wouldn't allow the IK to be keyed.

I could quite easily build an FK setup - as I could:
Control Curve (CC) drives Mo. G is physical parent to CC. G is grouped within Mo rig.
This carries the Control, while still allowing the MotionCapture to continue - though it breaks up the control rig to sitting inside the MotionCapture rig.
This means that this way there can't be a possibility of IK - as it needs an unbroken hierarchy.

As you can see in the notes below, I started thinking about baking keys.
Something I would later realise is that this would relieve the attributes of dual dependencies.

Another error i continued making (as I was testing all of this solely on the hips to toes) was to use parent constraints to all of the drivers - even though most of the controls don't translate - they only need to rotate within the hierarchy.

The last note shows my final breakthrough and trial (which was late at night up to the eyeballs with energy drinks).