Victor B. ZordanNicholas C. Van Der HorstUniversity of California, RiversideMapping optical motion capture datato skeletal motion using a physical modelMotivationMotivation Optical data + Skeleton Posture Problems: no perfect match, joint-center and rigid-body assumptions, limits on ranges of motion, aesthetic and production requirementsMotivation Isn't this problem solved by inverse kinematics (IK)in commercial solvers? Money... Filmbox is expensive!IK vs. our physical modeling approach Direct mapping of data - landmark for landmark Whole body solution - root gets no special priority Easily avoids singularities - straight limbs not a problem Avoids footskate - via ground contact reaction forces Data is becoming more available (e.g. CMU mocap site) BUT you want to map it to our own characterMotivation Recorded data is becoming more available (e.g. CMU site) but we want to map it to our own characterCommercial packages exist (like Kaydara's filmbox and Vicon's Motionbuilder) but they are expensiveAlso, their solution is based on inverse kinematics (IK) which has known problems that lead to noticable flaws: 1) Ill-defined singularities yielding limbs that do notbecome fully straight 2) Indirect, root-centric mapping leading to errorsthat propogate, e.g. footskate 3) Redundancies corrected by adhoc heuristics causing various quirk artifactsBackground Motion capture editing Too many to mention, see mocap session SIGGRAPH ’02Mapping to skeletons Silaghi, Plankers, Fua, Boulic, Fua, Thalmann ’98Molet, Boulic, Thalmann ’99Monzani, Baerlocher, Boulic, Thalmann ’00O`Brien, Bodenheimer, Brostow, Hodgins ’00Ude, Mann, Riley, Atkeson ’00Pollard, Hodgins, Riley, Atkeson ’02 Kovar, Schreiner, Gleicher '02Physics and motion captureRose, Guenter, Bodenheimer, Rose ’96Popovic & Witkin ’99Pollard ’99, Pollard & Behmaram-Mosavat ’00Zordan & Hodgins ’02Approach overview Simulation is used offlineto compute posturesInternal torque actuatorsallow the simulation to actas a flexible ragdollForce springs pull 'ragdoll'to reach the data, marker by markerContact (e.g. ground) maybe added through forceApproach overview foreach (data sample) { update [yellow] markers while (not still) { compute torques compute body forces if (active) compute contact forces update simulation }//while record posture}//forBasic Algorithmθd from rest positionk and b are stiffnessand damping, inertial scaled (Zordan & Hodgins '02)No joint limits τ= k( θd – θ ) – b( θ )Internal torque control PD-servo's control 3D ball joints at each articulation point to resist bendingτAdditional body forces Force-driven virtual 'landmarks' placed by hand guide the simulated bodies to follow the markersSprings pull the simulation tothe marker dataBody motion is damped Note, markers near joints affect both nearby bodiesτFmarker = -kf Xerror Fdamping = -bf VbodyFmarker FdampingAdditional constraint forces Avoiding foot/ground penetration and foot skateNormal ground forces flatten the foot on ground via a penalty methodMarker data is used to tag when each foot is sliding or notHorizontal friction forces (not shown) resist in opposite direction of the simulated point velocity when in slipImplementation details & examples 39 Degrees of freedom - simulated in ODE (free!) Runs about 2-3 frames/sec on 2.4 GHz Pentium IV 4 tuned parameters - torque stiffness & damping marker spring stiffness body force damping (plus, ground contact model)Posture errorRaw vs sim foot positionConclusion/future work Simple, easy to implement, and inexpensive Would dovetail nicely with a skeleton estimator Likely requires a two-pass process for motionsevere character retargeting Would benefit from a specialized marker set(markers spread over body parts with highly repeatable landmarks, for example) Should run interactively, to be used during the live motion capturee shootwww.cs.ucr.edu/~rglThank
View Full Document
Unlocking...