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.
Tuesday, 3 July 2012
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).
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).
The Goal
So after much searching I found this video.
http://www.youtube.com/watch?v=iTtEhWq-H1Y
It's a little dated - but does exactly what I want to be able to do. It allows the motion capture data to drive the skinned rig, while also giving the animator top level control (on separate controls) to edit the animation.
This means the mocap will ALWAYS run, and doesn't have to be directly edited.
Almost like layering the animation over the top.
This is what I think would really help with processing mocap files of several takes.
http://www.youtube.com/watch?v=iTtEhWq-H1Y
It's a little dated - but does exactly what I want to be able to do. It allows the motion capture data to drive the skinned rig, while also giving the animator top level control (on separate controls) to edit the animation.
This means the mocap will ALWAYS run, and doesn't have to be directly edited.
Almost like layering the animation over the top.
This is what I think would really help with processing mocap files of several takes.
MoBo
So I started to teach myself motionbuilder, using a small 5 part youtube tutorial.
http://www.youtube.com/watch?v=Hq1XTjnXlrw
I managed to repeat everything in the tutorial, and really got a feel for the whole program.
I also started looking at the filters (which was the main reason I wanted to use the program).
These allowed me to reduce the amount of keys on selected controls.
After a bit of tinkering I also managed to get the newly reduced keys into maya (after having exported it badly several times - rebaking keys to every frame).
However, I didn't see that many large advantages of motionbuilder. I find the HIK system quite clunky and difficult to edit effectively. It also seems destructive (perhaps I'm not doing it properly).
There must be a better way.
Feck.
When importing the newly imported keys of motion capture into maya - after using the retargetting tools it re-bakes the animation. So all of that finesse of reducing keys is effectively wasted.
I'll need to set up a system that edits them in waves perhaps. (I'll explain more about this soon).
http://www.youtube.com/watch?v=Hq1XTjnXlrw
I managed to repeat everything in the tutorial, and really got a feel for the whole program.
I also started looking at the filters (which was the main reason I wanted to use the program).
These allowed me to reduce the amount of keys on selected controls.
After a bit of tinkering I also managed to get the newly reduced keys into maya (after having exported it badly several times - rebaking keys to every frame).
However, I didn't see that many large advantages of motionbuilder. I find the HIK system quite clunky and difficult to edit effectively. It also seems destructive (perhaps I'm not doing it properly).
There must be a better way.
Feck.
When importing the newly imported keys of motion capture into maya - after using the retargetting tools it re-bakes the animation. So all of that finesse of reducing keys is effectively wasted.
I'll need to set up a system that edits them in waves perhaps. (I'll explain more about this soon).
The Retargetting
So now i was armed with my new menu buttons I needed to make good use of them.
I grabbed a really bad rig (knowing it was terrible) to test it out.
About the rig:
It was badly skinned.
The skeleton was simple.
The controls were buggered (the right arm control was constantly gimbal locked - it must've not been oriented properly)
So the state of play for retargetting the mocap was first to label the joints. This is something Maya 2012 has kept (thankfully!). After labelling each (not a daunting task at all due to the generic labelling options) it was time to connect the mo cap BVH to the General rig.
This is the direct result after it was attached.
I grabbed a really bad rig (knowing it was terrible) to test it out.
About the rig:
It was badly skinned.
The skeleton was simple.
The controls were buggered (the right arm control was constantly gimbal locked - it must've not been oriented properly)
So the state of play for retargetting the mocap was first to label the joints. This is something Maya 2012 has kept (thankfully!). After labelling each (not a daunting task at all due to the generic labelling options) it was time to connect the mo cap BVH to the General rig.
This is the direct result after it was attached.
Another Mocap File from Joshua Griffin on Vimeo.
The Great Hunt
So I'd remember that there was a way (before HIK in maya) to link motion capture files to rigs that could be different sizes/builds etc.
After much hunting I found this:
http://tech-artists.org/forum/showthread.php?2155-retargeting-animation-rigs
The video from this discussion used the HIK system, as well as a lengthy script - something that wasn't really suitable for me to explore.
I must also point out that I've had (and have heard other people having) bad experiences with the HIK rig setup in maya - leaving hidden keys and constraints within the rig - meaning editing gets messy and screws up very easily.
So with this in mind I remembered something from an Autodesk talk in Rave a while back, which was that in each edition of Maya they store legacy options (old functions and features). These are hidden away somewhere within the build - and have no menu options to access them.
This is where my hunt took me.
http://download.autodesk.com/us/maya/2009help/index.html?url=Skeleton__Retargeting__Retarget_Skeleton.htm,topicNumber=d0e335174
This is the link to some old autodesk wiki pages. This is exactly the option box i need to transfer the mocap to another skeleton. I also found this:
http://mayastation.typepad.com/maya-station/2010/04/fbik-or-hik.html
This was perfect! The exact code i needed!!
using this:
http://www.3dtrue.com/maya/5.html
I managed to fashion a menu bar (not a shelf button) so that the function would permanently be there.
I tried it out and got an error on the most important part.
The RetargetCharacterOptions; Didn't work. Giving me a // Error: Cannot find procedure "RetargetCharacterOptions". //
This wasn't great. Even after trying the WhatIs command i found here:
http://area.autodesk.com/forum/autodesk-maya/mel/cannot-find-procedure-clipeditorexportclip/
It wouldn't get found.
Not ready to admit defeat (despite spending about 3 hours trying to find out how to get this working) I went back to another autodesk wiki.
file:///C:/Program%20Files/Autodesk/Maya2011/docs/Maya2011/en_US/PyMel/generated/functions/pymel.core.animation/pymel.core.animation.retarget.html
I don't quite remember how I found this link - but it made me suspicious that all i was really looking for was a .mel file in the maya source (in my C: drive).
I found a retarget.mel file and opened it with notepad. Now, I'm not too great at coding, so a lot of what was in there I skipped - however RIGHT at the bottom I found a single string that led to the function I needed:
//
// Procedure Name:
// performRetarget
//
// Description:
// Create a clip and add the animatable attributes from the
// selected nodes. This procedure will also show the option box
// window if necessary as well as construct the command string
// that will create a clip with the current option box values.
//
// Input Arguments:
// 0 - Execute the command.
// 1 - Show the option box dialog.
// 2 - Return the command.
//
// Return Value:
// None.
From this I had to understand I didn't want to simply execute the command, nor get a return but to open the options box. So instead of "RetargetCharacterOptions;" I had to use "performRetarget(1);"
This worked beautifully, and once saved as a .mel and popped in maya's starup folder it always loads.
Hunt finished!!
After much hunting I found this:
http://tech-artists.org/forum/showthread.php?2155-retargeting-animation-rigs
The video from this discussion used the HIK system, as well as a lengthy script - something that wasn't really suitable for me to explore.
I must also point out that I've had (and have heard other people having) bad experiences with the HIK rig setup in maya - leaving hidden keys and constraints within the rig - meaning editing gets messy and screws up very easily.
So with this in mind I remembered something from an Autodesk talk in Rave a while back, which was that in each edition of Maya they store legacy options (old functions and features). These are hidden away somewhere within the build - and have no menu options to access them.
This is where my hunt took me.
http://download.autodesk.com/us/maya/2009help/index.html?url=Skeleton__Retargeting__Retarget_Skeleton.htm,topicNumber=d0e335174
This is the link to some old autodesk wiki pages. This is exactly the option box i need to transfer the mocap to another skeleton. I also found this:
http://mayastation.typepad.com/maya-station/2010/04/fbik-or-hik.html
This was perfect! The exact code i needed!!
using this:
http://www.3dtrue.com/maya/5.html
I managed to fashion a menu bar (not a shelf button) so that the function would permanently be there.
I tried it out and got an error on the most important part.
The RetargetCharacterOptions; Didn't work. Giving me a // Error: Cannot find procedure "RetargetCharacterOptions". //
This wasn't great. Even after trying the WhatIs command i found here:
http://area.autodesk.com/forum/autodesk-maya/mel/cannot-find-procedure-clipeditorexportclip/
It wouldn't get found.
Not ready to admit defeat (despite spending about 3 hours trying to find out how to get this working) I went back to another autodesk wiki.
file:///C:/Program%20Files/Autodesk/Maya2011/docs/Maya2011/en_US/PyMel/generated/functions/pymel.core.animation/pymel.core.animation.retarget.html
I don't quite remember how I found this link - but it made me suspicious that all i was really looking for was a .mel file in the maya source (in my C: drive).
I found a retarget.mel file and opened it with notepad. Now, I'm not too great at coding, so a lot of what was in there I skipped - however RIGHT at the bottom I found a single string that led to the function I needed:
//
// Procedure Name:
// performRetarget
//
// Description:
// Create a clip and add the animatable attributes from the
// selected nodes. This procedure will also show the option box
// window if necessary as well as construct the command string
// that will create a clip with the current option box values.
//
// Input Arguments:
// 0 - Execute the command.
// 1 - Show the option box dialog.
// 2 - Return the command.
//
// Return Value:
// None.
From this I had to understand I didn't want to simply execute the command, nor get a return but to open the options box. So instead of "RetargetCharacterOptions;" I had to use "performRetarget(1);"
This worked beautifully, and once saved as a .mel and popped in maya's starup folder it always loads.
Hunt finished!!
Better Results
So this is one of three of the better results (the rest will be used in later examples on rigs in maya/motionbuilder).
BVH Walk from Joshua Griffin on Vimeo.
I used a little pre-cleanup within ipisoft. There are a couple of little tools to use to clean jitters and smooth the overall motion slightly. It's much easier to do that here than in motionbuilder (at least that's what I've found so far).
What I now need to do is attach that motion to another rig - one that a character has a skin attached to.
BVH Walk from Joshua Griffin on Vimeo.
I used a little pre-cleanup within ipisoft. There are a couple of little tools to use to clean jitters and smooth the overall motion slightly. It's much easier to do that here than in motionbuilder (at least that's what I've found so far).
What I now need to do is attach that motion to another rig - one that a character has a skin attached to.
Subscribe to:
Posts (Atom)