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.
Tuesday, 3 July 2012
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.
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).
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.
Thursday, 28 June 2012
Baby Sitting
While using Ipi Soft I've been trying to monitor how I use the program and what I'm having to teach myself while I work.
I've found that the new updated version does quite a bit of the calibration work for you now - which is great. It was the most time consuming part.
However, it still makes errors on matching the skeleton to the kinect information. The errors can be as small as losing a hand for a frame or two, to whisking away the whole model, and these errors can really build on themselves. This is why I've got into the habit of baby sitting the process - pausing it, moving parts of the body into what i think should be the correct position and moving ahead again.
I've even started to try and trick the software. I think it must use the previous few frames (at least the one previous frame) as a starting point, then shifts into the correct position. To correct an error that continuously errors, and affects the next frames, I've started moving a body part for the last few frames - then tracking forward from the latest point.
In effect this is telling the software that the previous 2-3 frames are correct, use these and then shift slightly. By doing this I have a little more control over where the software 'thinks' that certain wayward body parts should go.
The T-Pose
I've found that the new updated version does quite a bit of the calibration work for you now - which is great. It was the most time consuming part.
However, it still makes errors on matching the skeleton to the kinect information. The errors can be as small as losing a hand for a frame or two, to whisking away the whole model, and these errors can really build on themselves. This is why I've got into the habit of baby sitting the process - pausing it, moving parts of the body into what i think should be the correct position and moving ahead again.
I've even started to try and trick the software. I think it must use the previous few frames (at least the one previous frame) as a starting point, then shifts into the correct position. To correct an error that continuously errors, and affects the next frames, I've started moving a body part for the last few frames - then tracking forward from the latest point.
In effect this is telling the software that the previous 2-3 frames are correct, use these and then shift slightly. By doing this I have a little more control over where the software 'thinks' that certain wayward body parts should go.
First Hurdle
So my first major issue was getting the system up and running and able to work.
This was installing drivers, getting the kinects online and making sure I could record.
After scouring the internet for answers as to why I couldn't use two kinects on the current software I found that we needed an update - so grabbed a demo. This is what I'll be using, the demo of Ipi Soft 2.0 with two Kinects.
For quite a while I was having issues with frame rates and the amount of data I was getting from the infra red. It was quite minimal, and had quite an effect on the output.
This is the first BVH animation. The reason the skeleton is so fast is due to the drops in the framerate of the recording. It went down to about 12fps - meaning it looks like an old black and white rollup film speed. This is pretty dire for what I need to be doing.
[edit] !! Figured out why it was at such a low framerate and can now use both kinects at 30fps perfectly. There were two main issues - and it's silly really. I was recording on Ipi Recorder both the infra red depth AND RGB data. This was too much for the kinects' bandwidth, which is why it was bottlenecked and started killing frames. Another issue (a slightly more minor one) was that I was running Ipi Studio (opposed to Ipi Recorder) at the same time. This obviously taxed the laptop too much and affected the output. Scary really.
This was installing drivers, getting the kinects online and making sure I could record.
After scouring the internet for answers as to why I couldn't use two kinects on the current software I found that we needed an update - so grabbed a demo. This is what I'll be using, the demo of Ipi Soft 2.0 with two Kinects.
For quite a while I was having issues with frame rates and the amount of data I was getting from the infra red. It was quite minimal, and had quite an effect on the output.
FirstBVHFast from Joshua Griffin on Vimeo.
This is the first BVH animation. The reason the skeleton is so fast is due to the drops in the framerate of the recording. It went down to about 12fps - meaning it looks like an old black and white rollup film speed. This is pretty dire for what I need to be doing.
[edit] !! Figured out why it was at such a low framerate and can now use both kinects at 30fps perfectly. There were two main issues - and it's silly really. I was recording on Ipi Recorder both the infra red depth AND RGB data. This was too much for the kinects' bandwidth, which is why it was bottlenecked and started killing frames. Another issue (a slightly more minor one) was that I was running Ipi Studio (opposed to Ipi Recorder) at the same time. This obviously taxed the laptop too much and affected the output. Scary really.
Where I was at
Before embarking on this project, I had trialled version 1.3 of Ipi Soft using 6 Playstation Eye cameras. The 6 cameras were formed in a complete circle and captured RGB data at 30fps. This was then calibrated in a dark space using a light (the luma from the RGB would be used in the calibration). The performance was then captured and later processed through Ipi Studio. Both calibration and processing would take 2-3 hours, and possibly longer if there was an issue with a recording.
The data from this, and subsequently the animation, wasn't of a high enough quality. The process also couldn't capture some faster movements.
I also was a complete novice when it came to cleaning motion capture. I had never used motionbuilder and had no idea how to clean keys (I still don't!!)
What's going on
So to build on my previous experience with the Ipi Soft kit, I've decided to research it's updated features and look into a pipeline to fit this into my main game creation project.
This will involve researching and trialling tests with the current software, creating a best practice and working method, creating a short wiki and several motion captures.
I also plan to look into motion capture clean-up. I'll be doing this in an academic capacity and also cleaning a choice few of my animations.
As I'll be looking into the pipeline, I'll also have quite an in-depth look at rigging and how I can best build a rig to edit the motion capture data.
This will involve researching and trialling tests with the current software, creating a best practice and working method, creating a short wiki and several motion captures.
I also plan to look into motion capture clean-up. I'll be doing this in an academic capacity and also cleaning a choice few of my animations.
As I'll be looking into the pipeline, I'll also have quite an in-depth look at rigging and how I can best build a rig to edit the motion capture data.
Subscribe to:
Posts (Atom)