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.
Friday, 26 October 2012
Thursday, 11 October 2012
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):
20121011 1412 47 from Joshua Griffin on Vimeo.
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.
Wednesday, 10 October 2012
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:
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.
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.
Monday, 8 October 2012
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] --------------------------------
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] --------------------------------
Monday, 1 October 2012
Visual
This is more of a visual explanation of what I've done for the pipeline:
MoCap Rig from Joshua Griffin on Vimeo.
MoCap Rig from Joshua Griffin on Vimeo.
Subscribe to:
Posts (Atom)