motionmapper.

exe

Motionmapper is a commandline tool designed specifically to remap motion from a "source" .smd skeleton to a "target" .smd skeleton. The target is assumed to have been built such that bone lengths and locations are somewhat different from the source. Used in it's default state, motionmapper does it's best to maintain the animation "feel" of the source animation, while solving for limb extremity location ie! feet on the ground and hands on weapons".#asic Usage!$motionmapper source%nimation.smd target&keleton.smd mappedMotion.smd'xecuting the above on a command line will execute a default mapping of the animation in the "source%nimation.smd" file to the skeleton defined in the first frame of animation in the "target&keleton.smd" file and will output the results into the "mappedMotion.smd" file.&ome notes on the .smd files used!(" Motionmapper determines it's mapping by comparing the source skeleton to the target skeleton. #ecause there is no "default pose" inherent in the .smd files, motionmapper uses the first "frame" of animation from both the source and target .smd files. Thus! a" #oth the source and target files must have a minimum of ( frame of animation. b" The target need not have more than ( frame of animation as it will be overwritten anyway.)" Motionmapper assumes both the source and target skeletons have '*%+T,- the same hierarchical structure with the exception of bone length and .oint orientation. Thus! a" #oth the source and target skeletons must have the same number of bones arranged in the same hierarchical order. b" /t is not neccesary for the source and target bones to have the same names as long as their locations in the hierarchy are e0uivalent. c" 1hen utili2ing template file options, bone names always refer to the names used in the "source" .smd file.3" Motionmapper assumes the skeletons are in the standard valve coordinate frame and built standard! a" %s far as the root is concerned "4" is up and down. b" The root is the only bone to have both translation and rotation animation, all other bones are rotation only. c" #one lengths are typically along "*" and if not universally .ointed rotate around "4"Using Template 5iles!1hen motionmapper is used without the 6template5ile argument, it does a "default" mapping from the source skeleton to the target skeleton. 7arious parameters in the mapping can be changed to achieve different motion effects. These parameters need to be placed in a text file and that file used as the option to the 6template5ile argument.8eneric Template 5iles!Motionmapper comes with a set of "generic" template files that should fulfill most your needs!(" walk.mmt #asic template for walk9run cycles and non6two handed weapon motions.)" two:anded1eapon.mmt#asic template for two handed, non6shoulder fired, weapon motions, wherein the left hand maintains it's exact relationship to the right but the right is motion mapped to the new skeleton.3" two:anded&houlder1eapon.mmt#asic template for two handed, shoulder fired, weapon motions, wherein the left hand maintains it's exact relationship to the right and the right hand maintains it's exact relationship to the shoulder &pine)".;ote that both the "two:anded1eapon" templates use "relative,ock", which assumes that the distance between the mapped .oint and it's "relative,ock" has not been altered in the destination skeleton. /f that distance has been

changed, it's possible to scale the "locked" .oint by altering the scalar argument at the end of the command.<" root,ock.mmtThis template is for motions wherein the character interacts with an ob.ect in the environment. ;o actual "mapping" is done to foot and hand positions. :owever, the new .oint lengths are solved for.;ote that the positions of the hands and feet will attempt to remain the same relative to the =>>T, which is not changed from the source animation. /f bones lengths are shortened significantly this may not be possible and you may get motion artifacts.%lternate Template 5iles!?lease note! 1hen a template file is used motionmapper abandons all "default" settings and depend entirely on the template file to guide it's mapping. Thus! (" 1hen using a template file, the template file must fully specify the mapping desired.To make this task easier, there are a few ways to build template files, one is to .ust use one of the @ or A template files supplied with motionmapper!default.mmttemplate(.mmttemplate).mmttemplate3.mmttemplate <.mmttemplateB.mmttemplate@.mmttemplateA.mmt#eside the "default.mmt" file, each one of these templates exhibit some form of varied motionmapping and have some comments regarding their function.%lternately you can use the 6printTemplate argument in motionmapper and pipe the output into a file and work from there!$motionmapper 6printTemplates $ myTemplate.txtThis will give you a file that is the e0uivalent to motionmapper's default settings, which you can then edit from there.This default file is not heavily commented and does not contain alot of explanation. %n explanation of the default template settings and their variations follows.Template &ettingsTemplate files contain actions and attributes. They both take arguments on the same line. The main difference is that actions can be scheduled and attributes are the parameters for those actions. /t's admittedly a little confusing and may be changed at some .uncture into a more consistent form. 1e will discuss them as they appear in the default.mmt file.root&caleCoint 7alve#iped.#ipD(E,E5ootThe root&caleCoint command takes one argument that specifies which two .ointed limb to base it's root motion scaling on. This is typically one of the feet as an alteration in the length of the legs would usually be the only reason to scale the root.;ote! specifying a limb that isn't also specified in a "twoCoint/F&olve" below" will most certainly result in slipping feet.root&cale%mount (.D1hile the argument to this attribute is a floating point value, this attribute is included for the sole purpose of turning root scaling on and off, which will be discussed in the "%lternate Mappings" section.to5loor4 ).AAAAThis attribute specifies where along the "2" axis the "floor" lives. This attribute affects both the root scaling as well as the "oneCoint?lane+onstraint" below".twoCoint/F&olve 7alve#iped.#ipD(E,E5ootThis action can actually scheduled multiple times in the same template file and preferably" on different .oints. The ob.ective of this command and it's various attributes is to establish a position based relationship between the .oint and it's grandparent in the source skeleton and then to replicate that relationship in the target. The various attributes specify ways of altering that relationship. -ou'll notice in the default.mmt template file that there are < twoCoint/F&olves scheduled!7alve#iped.#ipD(E,E5oot7alve#iped.#ipD(E=E5oot7alve#iped.#ipD(

E,E:and7alve#iped.#ipD(E=E:andreverse&olve D.DThis attribute tells the /F solver to bend the .oint one way or the other. -ou'll notice looking at the template file that elbows are actually bent the reverse of knees.extremity&cale (.DThis attribute is determining whether or not to match the motion of the extremity being solved for to it's new limb length or to maintain the same scale of animation as it's source. ;ote! this attribute, when applied to feet, is inimately related to root&cale%mount and they should be set the same.limb=oot>ffset&cale (.D (.D D.DThis attribute is specifying how much and along which axis in root space" to mimic the change in the limb's root or the .oint being solved's grandparent. /n other words, if the hips are now wider, do we want the feet to be spread wider as wellG &ame goes for shoulders, do we want the hands to be spread wider if the shoulders are widerG The reason for the 3 axis argument is this! /f the hips of the new skeleton are "lower", we don't actually want to offset the feet by that same amount as it will put them through the floor. The opposite could be potentially be true for the arms, if the shoulders are wider, the back shorter and your animation includes holding a weapon you would probably want the hands offset in vertical space so that they aren't up over the character's head but not neccessarily set wider apart as they would not longer be properly holding a weapon.relative,ock 7alve#iped.#ipD(E=E:and (.DThis attribute is specifically for keep on hand in an absolute relationship to another hand, for holding weapons, etc. This attribute is typcially only set on one of the hands and hand being locked to needs to be solved before the hand being locked. The scalar value at the end of the attribute can be used to scale the location of the locked hand in the space of the "locking" hand, effectively growing or shrinking their relative distance smaller or larger weapons".oneCoint?lane+onstraint 7alve#iped.#ipD(E,EToeDThis is a simple one .oint plane constraint that ad.usts the parent .oint such that the specified bone will not penetrate the "floor" as defined by the "toe5loor4" attribute above. This is for keep toes above the ground when a twoCoint/F&olve has pushed them below.;ote! This solve only works if the "foot" node is still above the ground, which it should always be if you are executing a reasonable mapping. &pecial Template +ommands!There are a couple of "special" commands that can be placed in a template file that are related to skeleton alteration and were primarily used for testing. They can be used for skeletal changes however.".oint&cale"example!.oint&cale 7alve#iped.#ipD(E,E5oot (.BThis would scale the left foot bone in the destination skeleton by a factor of (.B"skeleton&cale"example!skeleton&cale (.BThis would scale every bone in the destination skeleton by a factor of (.B