This document provides a comprehensive mapping of joint hierarchies across the major humanoid animation and modeling standards used in contemporary digital content production. As motion capture, character animation, and avatar systems increasingly require cross-platform compatibility, understanding the semantic relationships between different skeletal representations becomes critical for robust retargeting, analysis, and content pipeline development.
Humanoid skeletal systems, while varying significantly in naming conventions and hierarchical depth, share fundamental anatomical constraints that enable systematic cross-format mapping. The underlying biomechanical structure remains consistent across systems, so the challenge lies in the divergent approaches each standard takes.
- Joint naming conventions Lexical variations abound, e.g. "LeftArm" vs "lhumerus" vs "leftUpperArm".
- Hierarchical depth The SMPL scheme has 24 joints, HAnim 74.
- Optional component inclusion Different schemes may include fingers, facial controls, twist bones, secondary dynamics.
- Coordinate systems All the schemes root at pelvis/hips, but channel orders vary.
- Semantic vs. explicit mapping Some schemes like Unity Mecanim's are semantic mappings, others involve direct bone correspondence.
The analysis studies nine primary standards representing the current landscape of humanoid skeletal representation:
Production Standards:
- OpenUSD - Pixar's Universal Scene Description production sample featuring detailed facial controls
- VRM - VRoid humanoid avatar specification with its standardized 55-bone mapping
- Mixamo - Adobe's animation retargeting system (BVH-compatible)
Motion Capture Formats:
- BVH (Biovision Hierarchy) - Widespread motion capture interchange format
- ASF/AMC (Acclaim) - A commonly used motion capture standard with explicit DOF specification
Research Standards:
- HAnim - Web3D Consortium humanoid animation specification
- SMPL/SMPL-X - Statistical body model with extended facial/hand articulation
Engine Integrations:
- Unreal Engine Mannequin - Epic Games' reference skeleton with twist bone support
- Unity Mecanim - Semantic humanoid mapping system
- General BVH - Canonical motion capture representation
Each standard is examined across three dimensions:
- Structural Analysis - Joint count, hierarchical depth, optional components
- Semantic Mapping - Cross-format joint correspondence and naming patterns
- Technical Constraints - Rotation orders, coordinate systems, channel specifications
A unified mapping table provides direct semantic correspondence.
OpenUSD's humanoid skeletal representation is intended as an exemplar of Pixar's production-scale character structure. The exemplar prioritizes comprehensive facial articulation and detailed extremity control, reflecting feature animation demands where subtle expression and gesture fidelity directly impact narrative effectiveness.
The OpenUSD skeleton demonstrates strong architectural alignment with traditional animation workflows. Joint naming follows descriptive conventions that balance human readability with systematic processing, a critical consideration for pipeline tools that generalize and operate across multiple content creation applications.
___ _ _ ___ ___
/ _ \ _ __ ___ _ _| | | / __| \
| (_) | '_ \/ -_) ' \ |_| \__ \ |) |
\___/| .__/\___|_||_\___/|___/___/
|_|
Hips
├── Torso
│ └── Chest
│ └── UpChest
│ ├── Neck
│ │ └── Head
│ │ ├── LEye
│ │ ├── LUpLidInner
│ │ ├── LUpLidOuter
│ │ ├── LUpLidTip
│ │ ├── LUpLidTipInner
│ │ ├── LUpLidTipOuter
│ │ ├── LLoLidInner
│ │ ├── LLoLidOuter
│ │ ├── LLoLidTip
│ │ ├── LLoLidTipInner
│ │ ├── LLoLidTipOuter
│ │ ├── LLidInnerCorner
│ │ ├── LLidOuterCorner
│ │ ├── REye
│ │ ├── RUpLidInner
│ │ ├── RUpLidOuter
│ │ ├── RUpLidTip
│ │ ├── RUpLidTipInner
│ │ ├── RUpLidTipOuter
│ │ ├── RLoLidInner
│ │ ├── RLoLidOuter
│ │ ├── RLoLidTip
│ │ ├── RLoLidTipInner
│ │ ├── RLoLidTipOuter
│ │ ├── RLidInnerCorner
│ │ ├── RLidOuterCorner
│ │ ├── Nose
│ │ ├── Chin
│ │ ├── LChin
│ │ ├── RChin
│ │ ├── LCheek
│ │ ├── RCheek
│ │ ├── LEar
│ │ ├── REar
│ │ ├── Mouth
│ │ ├── UpLip
│ │ ├── LUpLip
│ │ ├── RUpLip
│ │ ├── LLipCorner
│ │ ├── RLipCorner
│ │ ├── LoLip
│ │ ├── LLoLip
│ │ ├── RLoLip
│ │ ├── LBrow
│ │ └── RBrow
│ ├── LShldr
│ │ └── LArm
│ │ └── LElbow
│ │ └── LHand
│ │ ├── LThumb
│ │ │ └── LThumbMid
│ │ │ └── LThumbTip
│ │ │ └── LThumbEnd
│ │ ├── LIndex
│ │ │ └── LIndexMid
│ │ │ └── LIndexTip
│ │ │ └── LIndexEnd
│ │ ├── LMiddle
│ │ │ └── LMiddleMid
│ │ │ └── LMiddleTip
│ │ │ └── LMiddleEnd
│ │ ├── LRing
│ │ │ └── LRingMid
│ │ │ └── LRingTip
│ │ │ └── LRingEnd
│ │ └── LPinky
│ │ └── LPinkyMid
│ │ └── LPinkyTip
│ │ └── LPinkyEnd
│ └── RShldr
│ └── RArm
│ └── RElbow
│ └── RHand
│ ├── RThumb
│ │ └── RThumbMid
│ │ └── RThumbTip
│ │ └── RThumbEnd
│ ├── RIndex
│ │ └── RIndexMid
│ │ └── RIndexTip
│ │ └── RIndexEnd
│ ├── RMiddle
│ │ └── RMiddleMid
│ │ └── RMiddleTip
│ │ └── RMiddleEnd
│ ├── RRing
│ │ └── RRingMid
│ │ └── RRingTip
│ │ └── RRingEnd
│ └── RPinky
│ └── RPinkyMid
│ └── RPinkyTip
│ └── RPinkyEnd
├── LLeg
│ └── LKnee
│ └── LFoot
│ └── LToes
│ └── LTip
└── RLeg
└── RKnee
└── RFoot
└── RToes
└── RTip
Joint Count: 94 total joints providing comprehensive facial and extremity articulation
Hierarchical Depth: Finger ends are twelve links deep from the root.
Distinctive Characteristics:
- Extensive facial rig: 26 dedicated facial joints including bilateral eyelid control systems (inner/outer/tip variants), fine mouth control, and minor extra influences throughout the head, providing granular expression capability
- Anatomically descriptive naming: Joint identifiers balance technical precision with semantic clarity ("LUpLidTipInner" explicitly describes anatomical position and function)
- Symmetric bilateral structure: Complete left/right mirroring across all appendages and facial features, enabling generalization of rigging and animation tools
- Four-segment finger chains: Full phalangeal representation (base → mid → tip → end) enabling detailed hand animation
Technical Constraints:
- Root transformation: Applied at
Hipsjoint with standard translation and rotation channels - Coordinate system: Follows right-handed Y-up convention
- Joint orientation: Local joint spaces maintain anatomically consistent forward/up/right orientations
- Scaling compatibility: Hierarchical structure supports non-uniform scaling operations across joint chains
Cross-Format Mapping Considerations:
The OpenUSD specification's comprehensive joint set creates mapping asymmetries when retargeting to minimal skeletal standards. Key challenges include:
- Facial detail reduction: Most target formats lack equivalent eyelid/lip articulation, requiring selective joint exclusion or proxy mapping
- Finger complexity: Four-segment finger chains exceed typical three-segment implementations, necessitating intermediate joint interpolation or end-effector mapping
- Naming convention translation: Descriptive identifiers require systematic conversion to target format conventions (e.g., "LShldr" → "LeftShoulder" → "leftShoulder")
Pipeline Integration Strengths:
- High-fidelity source: Comprehensive joint coverage supports downstream simplification without information loss
- Semantic clarity: Descriptive naming reduces ambiguity during automated mapping operations
- Production-validated: Extensive use in feature animation provides robust real-world validation of hierarchical design decisions
The OpenUSD skeletal framework represents a maximal approach to humanoid representation, prioritizing expressive completeness over computational efficiency—a design philosophy that strongly aligns with content creation workflows requiring comprehensive character control.
VRM (Virtual Reality Model) emerged from the Japanese VTuber and virtual avatar ecosystem, standardized by the VRM Consortium to address the fragmentation in humanoid character representation across virtual reality and real-time applications. Unlike production-focused standards that prioritize maximum expressiveness, VRM establishes a canonical 55-bone humanoid specification optimized for real-time performance and cross-platform avatar interchange.
The specification builds upon Unity's Humanoid Avatar system while codifying explicit bone requirements and optional components. This approach enables automatic retargeting between arbitrary skeletal rigs and the VRM standard, facilitating avatar portability across VR applications, social platforms, and streaming software.
VRM's design philosophy emphasizes semantic consistency over naming flexibility—each humanoid bone maps to a predefined role with standardized functionality, challenging the ad hoc skeletal variations common in game development pipelines.
__ _____ __ __
\ \ / / _ \ \/ |
\ V /| / |\/| |
\_/ |_|_\_| |_|
root [optional]
└─ hips
├─ spine
│ ├─ chest [optional]
│ │ ├─ upperChest [optional]
│ │ │ └─ neck [optional]
│ │ │ └─ head
│ │ │ ├─ leftEye [optional]
│ │ │ ├─ RightEye [optional]
│ │ │ └─ jaw [optional]
│ ├─ leftShoulder [optional]
│ │ └─ leftUpperArm
│ │ └─ leftLowerArm
│ │ └─ leftHand
│ │ ├─ leftThumbMetacarpal [optional]
│ │ │ └─ leftThumbProximal [optional]
│ │ │ └─ leftThumbDistal [optional]
│ │ ├─ leftIndexProximal [optional]
│ │ │ └─ leftIndexIntermediate [optional]
│ │ │ └─ leftIndexDistal [optional]
│ │ ├─ leftMiddleProximal [optional]
│ │ │ └─ leftMiddleIntermediate [optional]
│ │ │ └─ leftMiddleDistal [optional]
│ │ ├─ leftRingProximal [optional]
│ │ │ └─ leftRingIntermediate [optional]
│ │ │ └─ leftRingDistal [optional]
│ │ └─ leftLittleProximal [optional]
│ │ └─ leftLittleIntermediate [optional]
│ │ └─ leftLittleDistal [optional]
│ └─ rightShoulder [optional]
│ └─ rightUpperArm
│ └─ rightLowerArm
│ └─ rightHand
│ ├─ rightThumbMetacarpal [optional]
│ │ └─ rightThumbProximal [optional]
│ │ └─ rightThumbDistal [optional]
│ ├─ rightIndexProximal [optional]
│ │ └─ rightIndexIntermediate [optional]
│ │ └─ rightIndexDistal [optional]
│ ├─ rightMiddleProximal [optional]
│ │ └─ rightMiddleIntermediate [optional]
│ │ └─ rightMiddleDistal [optional]
│ ├─ rightRingProximal [optional]
│ │ └─ rightRingIntermediate [optional]
│ │ └─ rightRingDistal [optional]
│ └─ rightLittleProximal [optional]
│ └─ rightLittleIntermediate [optional]
│ └─ rightLittleDistal [optional]
├─ leftUpperLeg
│ └─ leftLowerLeg
│ └─ leftFoot
│ └─ leftToes [optional]
└─ rightUpperLeg
└─ rightLowerLeg
└─ rightFoot
└─ rightToes [optional]
Secondary (Spring) Bones [VRM extension nodes; optional and arbitrary]
├─ J_HairBack [example; arbitrary name]
│ ├─ J_HairBack_1
│ │ └─ J_HairBack_2
├─ J_HairSideLeft
│ └─ J_HairSideLeft_1
├─ J_SkirtFront
│ └─ J_SkirtFront_1
└─ ... (other dynamic bone chains as needed)
Joint Count: 55 standardized humanoid bones (15 required, 41 optional)
Hierarchical Depth: Maximum 9 levels (HumanoidRoot → Hips → Spine chains and extremity branches)
Distinctive Characteristics:
- Standardized bone roles: Each joint maps to explicit semantic function within the humanoid specification, eliminating naming ambiguity
- Required vs. optional stratification: Core 24 bones ensure basic humanoid functionality, while optional bones enable enhanced detail (fingers, facial features, additional spine segments)
- Unity Humanoid compatibility: Direct mapping to Unity's Avatar system enables immediate integration with existing animation tools and workflows
- Real-time optimization: Joint selection balances expressive capability with computational constraints for VR and mobile applications
Technical Constraints:
- Root transformation: Applied at
hipsjoint following Unity conventions - Coordinate system: Right-handed Y-up alignment with Unity's coordinate space
- Bone naming: Fixed identifiers per specification (e.g.,
leftUpperArm,rightIndexProximal) prevent arbitrary variation - Animation compatibility: Supports Unity's Mecanim retargeting system for cross-rig animation transfer
Semantic Mapping Framework:
VRM's core innovation lies in its semantic bone mapping system:
- Anatomical roles: Each bone corresponds to specific anatomical function rather than arbitrary naming
- Cross-rig retargeting: Automatic mapping between source rigs and VRM standard based on bone roles
- Validation system: Specification compliance checking ensures avatar compatibility across VRM-supporting applications
- Extension points: Optional bone categories allow enhanced detail while maintaining core compatibility
Cross-Format Mapping Considerations:
VRM's semantic approach creates distinct advantages and challenges:
Strengths:
- Automatic retargeting: Semantic roles enable direct mapping to/from other humanoid standards
- Guaranteed compatibility: Specification compliance ensures cross-application functionality
- Clear documentation: Fixed bone roles eliminate interpretation ambiguity
Limitations:
- Facial expression constraints: Limited facial bone support requires blendshape-based or texture-based expression systems
- Custom rig integration: Non-standard skeletal structures require manual mapping to VRM roles
Pipeline Integration Strengths:
- Unity ecosystem: Native integration with Unity toolchain and asset pipeline
- Avatar marketplace: Standardization enables avatar trading and marketplace development
- Cross-platform deployment: Consistent representation across VR platforms, mobile apps, and web applications
- Community adoption: Growing ecosystem of tools and content creation applications
Real-Time Performance Characteristics:
VRM's design explicitly addresses performance constraints in interactive applications:
- Bone count optimization: 55-bone maximum prevents excessive computational overhead
- LOD compatibility: Hierarchical optional bones enable level-of-detail reduction
- GPU skinning efficiency: Standard bone layouts optimize vertex shader performance
- Memory footprint: Predictable skeletal structure enables efficient memory allocation
The VRM specification represents a convergence approach—establishing common ground between diverse skeletal representations while maintaining practical constraints for real-time applications. This positions VRM as particularly valuable for avatar-centric applications where cross-platform compatibility outweighs maximum expressive detail.
HAnim (Humanoid Animation) represents the Web3D Consortium's formal specification for humanoid character representation within VRML/X3D environments. Developed through academic and industrial collaboration during the late 1990s, HAnim addresses the fundamental challenge of humanoid animation interchange across heterogeneous 3D web applications.
The specification's architectural foundation reflects early web-based 3D constraints—emphasizing standardized joint definitions and precise anatomical correspondence while maintaining computational efficiency for browser-based rendering. Unlike contemporary standards that evolved from game engines or production pipelines, HAnim emerged from the distributed computing paradigm where character data must traverse network boundaries and execute within resource-constrained client environments.
HAnim's enduring relevance stems from its rigorous anatomical grounding and explicit joint role definitions. The specification provides comprehensive coverage of human skeletal structure while maintaining clear distinctions between required, optional, and secondary joint categories—a taxonomic approach that enables both minimal implementations and detailed anatomical modeling.
_ _ _ _
| || | /_\ _ _ (_)_ __
| __ |/ _ \| ' \| | ' \
|_||_/_/ \_\_||_|_|_|_|_|
HumanoidRoot
├─ sacroiliac (pelvis/hip root)
│ ├─ l_hip
│ │ └─ l_knee
│ │ ├─ l_ankle
│ │ │ ├─ l_subtalar (optional)
│ │ │ │ └─ l_midtarsal (optional)
│ │ │ │ └─ l_metatarsal (secondary)
│ │ │ └─ l_toe (optional)
│ │ └─ l_patella (secondary)
│ └─ r_hip
│ ├─ r_knee
│ ├─ r_ankle
│ │ ├─ r_subtalar (optional)
│ │ │ └─ r_midtarsal (optional)
│ │ │ └─ r_metatarsal (secondary)
│ │ └─ r_toe (optional)
│ └─ r_patella (secondary)
├─ vl5 (lumbar base)
│ ├─ vt10 (thoracic base)
│ │ ├─ vt6 (upper thoracic)
│ │ │ ├─ vt1 (cervical base)
│ │ │ │ ├─ skullbase
│ │ │ │ │ └─ skull (head mesh anchor)
│ │ │ │ │ ├─ l_eyeball_joint (optional)
│ │ │ │ │ ├─ r_eyeball_joint (optional)
│ │ │ │ │ ├─ jaw (optional)
│ │ │ │ │ └─ facial_* (secondary optional facial rig)
│ │ │ │ ├─ l_sternoclavicular
│ │ │ │ │ ├─ l_acromioclavicular
│ │ │ │ │ │ ├─ l_shoulder (often equivalent to acromioclavicular)
│ │ │ │ │ │ │ ├─ l_elbow
│ │ │ │ │ │ │ │ └─ l_wrist
│ │ │ │ │ │ │ │ ├─ l_thumb1 (optional)
│ │ │ │ │ │ │ │ │ └─ l_thumb2 (optional)
│ │ │ │ │ │ │ │ │ └─ l_thumb3 (optional)
│ │ │ │ │ │ │ │ ├─ l_index1 (optional)
│ │ │ │ │ │ │ │ │ └─ l_index2 (optional)
│ │ │ │ │ │ │ │ │ └─ l_index3 (optional)
│ │ │ │ │ │ │ │ ├─ l_middle1 (optional)
│ │ │ │ │ │ │ │ │ └─ l_middle2 (optional)
│ │ │ │ │ │ │ │ │ └─ l_middle3 (optional)
│ │ │ │ │ │ │ │ ├─ l_ring1 (optional)
│ │ │ │ │ │ │ │ │ └─ l_ring2 (optional)
│ │ │ │ │ │ │ │ │ └─ l_ring3 (optional)
│ │ │ │ │ │ │ │ ├─ l_pinky1 (optional)
│ │ │ │ │ │ │ │ │ └─ l_pinky2 (optional)
│ │ │ │ │ │ │ │ │ └─ l_pinky3 (optional)
│ │ │ │ │ │ │ │ └─ l_carpal_extra (secondary)
│ │ │ │ │ │ │ └─ l_ulna_radius (secondary)
│ │ │ │ │ │ └─ l_scapula (secondary)
│ │ │ │ │ └─ clavicle anchor (optional helper)
│ │ │ │ └─ r_sternoclavicular
│ │ │ │ ├─ r_acromioclavicular
│ │ │ │ │ └─ r_shoulder
│ │ │ │ │ ├─ r_elbow
│ │ │ │ │ │ ├─ r_wrist
│ │ │ │ │ │ │ ├─ r_thumb1/2/3 (optional)
│ │ │ │ │ │ │ ├─ r_index1/2/3 (optional)
│ │ │ │ │ │ │ ├─ r_middle1/2/3 (optional)
│ │ │ │ │ │ │ ├─ r_ring1/2/3 (optional)
│ │ │ │ │ │ │ ├─ r_pinky1/2/3 (optional)
│ │ │ │ │ │ │ └─ r_carpal_extra (secondary)
│ │ │ │ │ │ └─ r_ulna_radius (secondary)
│ │ │ │ │ └─ r_scapula (secondary)
│ │ │ │ └─ clavicle anchor (optional)
│ │ │ └─ vt6 ribs anchors (secondary)
│ │ └─ vt10 ribs anchors (secondary)
│ └─ vl5 lower back anchor (secondary)
└─ extra pelvic markers (optional for mocap retarget)
Joint Count: 74 joints maximum (core subset required, extended set optional)
Hierarchical Depth: 16 levels
Distinctive Characteristics:
- Anatomically precise nomenclature: Joint names correspond directly to anatomical structures (sacroiliac, sternoclavicular, acromioclavicular) rather than functional descriptors
- Medical accuracy: Skeletal topology reflects actual human anatomy including intermediate joints often omitted in simplified representations
- Explicit joint role taxonomy: Clear categorization of required, optional, and secondary joints enables implementation flexibility
- Scientific validation: Specification development involved medical and biomechanical expertise, ensuring anatomical correctness
Technical Constraints:
- Coordinate system: Follows X3D right-handed coordinate conventions
- Joint orientation: Local coordinate systems align with anatomical axes (flexion/extension, abduction/adduction, rotation)
- Transformation hierarchy: Strict parent-child relationships reflecting anatomical joint dependencies
- Scaling consistency: Segment lengths and proportions maintain anatomical relationships across scale variations
Anatomical Fidelity Framework:
HAnim's core strength lies in its anatomical correspondence:
- Medical nomenclature: Joint identifiers use established anatomical terminology
- Skeletal topology: Joint relationships mirror actual human skeletal connections
- Range of motion: Implicit joint constraints reflect natural human movement limitations
- Proportional relationships: Segment ratios correspond to anthropometric data
Cross-Format Mapping Considerations:
HAnim's anatomical precision creates specific mapping challenges:
Strengths:
- Scientific foundation: Anatomical accuracy provides authoritative mapping reference
- Comprehensive coverage: Extended joint set accommodates detailed character requirements
- Clear specifications: Explicit joint role definitions reduce mapping ambiguity
Challenges:
- Nomenclature translation: Medical terminology requires mapping to colloquial naming conventions
- Joint complexity: Anatomical precision exceeds requirements for many application domains
- Implementation overhead: Full specification compliance requires extensive joint support
Web3D Integration Characteristics:
HAnim's web-focused design addresses distributed 3D application requirements:
- Network efficiency: Standardized joint definitions enable compact character transmission
- Browser compatibility: Computational constraints favor efficient skeletal representations
- Interoperability: Common joint vocabulary enables cross-application character exchange
- Progressive enhancement: Tiered joint requirements support capability-based implementations
Academic and Research Applications:
HAnim's rigorous foundation makes it particularly valuable for scientific applications:
- Biomechanical analysis: Anatomical accuracy supports movement analysis and simulation
- Medical visualization: Joint correspondence enables clinical application development
- Motion capture validation: Provides authoritative reference for mocap data interpretation
- Anthropometric studies: Standardized proportions support human factors research
Implementation Flexibility:
The specification's tiered approach accommodates diverse deployment scenarios:
- Minimal implementations: Core joint subset enables basic humanoid functionality
- Extended detail: Optional joints provide enhanced anatomical fidelity
- Application-specific subsets: Selective joint implementation based on functional requirements
- Progressive loading: Hierarchical structure supports incremental detail addition
Legacy and Evolution:
HAnim's influence extends beyond its immediate application domain:
- Standard precedent: Established patterns for anatomical joint specification
- Cross-domain adoption: Principles adapted by subsequent humanoid standards
- Academic continuity: Ongoing research and development within Web3D community
- Specification stability: Long-term consistency enables reliable implementation targets
The HAnim specification represents a foundational approach to humanoid skeletal standardization—prioritizing anatomical accuracy and scientific rigor over application-specific optimizations. This positions HAnim as particularly valuable for applications requiring medical accuracy, biomechanical analysis, or cross-domain character data exchange where anatomical precision takes precedence over performance optimization.
SMPL-X (Skinned Multi-Person Linear Model - eXpressive) represents the evolution of statistical human body modeling from research laboratories toward practical computer vision and machine learning applications. Developed by the Max Planck Institute for Intelligent Systems, SMPL-X extends the foundational SMPL framework with comprehensive hand articulation and facial expression modeling, creating a unified parametric representation of human form and motion.
The model's architectural foundation diverges significantly from traditional animation-focused skeletal systems. Rather than optimizing for artist workflow or real-time performance, SMPL-X prioritizes statistical consistency and parameter space efficiency. The skeletal structure serves as a deformation framework for a learned body model where shape, pose, and expression emerge from compact parameter vectors rather than explicit joint manipulations.
This parametric approach enables SMPL-X to represent vast populations of human body variations through statistical distributions—a capability that proves essential for computer vision applications requiring robust human pose estimation, body shape analysis, and motion synthesis from limited observational data.
___ __ __ ___ _ __ __
/ __| \/ | _ \ | __\ \/ /
\__ \ |\/| | _/ |_|___> <
|___/_| |_|_| |____| /_/\_\
pelvis
├── left_hip
│ └── left_knee
│ └── left_ankle
│ ├── left_foot
│ │ └── left_toe (optional)
│ └── left_heel (optional, used in some rigs)
├── right_hip
│ └── right_knee
│ └── right_ankle
│ ├── right_foot
│ │ └── right_toe (optional)
│ └── right_heel (optional)
└── spine1
└── spine2
└── spine3 (thorax)
├── neck
│ └── head
│ ├── jaw (optional, face expression)
│ └── eye_left / eye_right (optional)
│ └── facial_expression_joints (optional, ~51 blendshape proxies)
├── left_clavicle
│ └── left_shoulder
│ └── left_elbow
│ └── left_wrist
│ ├── left_hand_index1
│ │ ├── left_hand_index2
│ │ └── left_hand_index3
│ ├── left_hand_middle1
│ │ ├── left_hand_middle2
│ │ └── left_hand_middle3
│ ├── left_hand_ring1
│ │ ├── left_hand_ring2
│ │ └── left_hand_ring3
│ ├── left_hand_pinky1
│ │ ├── left_hand_pinky2
│ │ └── left_hand_pinky3
│ └── left_hand_thumb1
│ ├── left_hand_thumb2
│ └── left_hand_thumb3
└── right_clavicle
└── right_shoulder
└── right_elbow
└── right_wrist
├── right_hand_index1
│ ├── right_hand_index2
│ └── right_hand_index3
├── right_hand_middle1
│ ├── right_hand_middle2
│ └── right_hand_middle3
├── right_hand_ring1
│ ├── right_hand_ring2
│ └── right_hand_ring3
├── right_hand_pinky1
│ ├── right_hand_pinky2
│ └── right_hand_pinky3
└── right_hand_thumb1
├── right_hand_thumb2
└── right_hand_thumb3
Joint Count: 127 joints total (24 body + 30 hand + 51 face + 22 additional articulation)
Hierarchical Depth: Maximum 11 levels
Distinctive Characteristics:
- Statistical foundation: Joint positions and orientations derived from population-scale body scan datasets rather than idealized anatomical models
- Parametric deformation: Skeletal structure supports learned shape and pose spaces enabling continuous body variation
- Expressive completeness: Unified representation of body pose, hand gestures, and facial expressions within single parametric framework
- Research validation: Extensive evaluation across computer vision benchmarks and motion capture datasets
Technical Constraints:
- Parameter space: Joint configurations constrained by learned statistical distributions from training data
- Coordinate system: Follows computer vision conventions with specific camera/world coordinate relationships
- Deformation model: Linear blend skinning with learned corrective blend shapes for realistic surface deformation
- Optimization targets: Designed for gradient-based fitting algorithms rather than manual animation workflows
Statistical Modeling Framework:
SMPL-X's core innovation lies in its parametric body representation:
- Shape parameters: Compact encoding of body shape variation across populations
- Pose parameters: Axis-angle joint rotations with learned prior distributions
- Expression parameters: Facial expression coefficients driving blendshape-like deformations
- Translation parameters: Global body positioning and orientation in world space
Computer Vision Integration:
The model's design explicitly addresses machine learning application requirements:
- Differentiable representation: All model components support gradient-based optimization
- Compact parameterization: Low-dimensional parameter vectors enable efficient optimization
- Prior distributions: Learned statistical priors regularize fitting to plausible human configurations
- Multi-modal data: Unified framework accommodates RGB images, depth data, and motion capture input
Cross-Format Mapping Considerations:
SMPL-X's research origins create distinct mapping characteristics:
Strengths:
- Comprehensive coverage: Unified body, hand, and face representation
- Statistical validity: Population-based training ensures realistic human variation
- Computer vision compatibility: Optimized for automated pose estimation and fitting
Challenges:
- Non-standard naming: Research-oriented joint identifiers require systematic translation
- Parameter dependencies: Joint configurations coupled through statistical models rather than independent
- Artist workflow: Parametric interface differs significantly from traditional animation controls
Research and Commercial Applications:
SMPL-X enables diverse application domains:
- Human pose estimation: 3D pose recovery from 2D images and video
- Avatar generation: Data-driven character creation with realistic proportions
- Motion synthesis: Statistically plausible human movement generation
- Biometric analysis: Body shape and motion analysis for identification and health assessment
- Augmented reality: Real-time human tracking and avatar animation
- Fashion and retail: Virtual try-on systems with accurate body shape modeling
Performance Characteristics:
The model balances expressive capability with computational efficiency:
- Parameter count: 229 total parameters (10 shape + 156 pose + 50 expression + 13 additional)
- Mesh resolution: 10,475 vertices providing detailed surface representation
- Evaluation speed: Optimized implementations achieve real-time performance on modern GPUs
- Memory footprint: Compact parameter representation enables efficient storage and transmission
Validation and Benchmarking:
SMPL-X underwent extensive validation across research domains:
- Motion capture accuracy: Quantitative evaluation against ground-truth mocap data
- Cross-dataset generalization: Performance validation across diverse population datasets
- Application benchmarks: Standardized evaluation protocols for pose estimation and body fitting
- User studies: Perceptual validation of generated body shapes and motions
Evolution from SMPL:
SMPL-X represents significant extensions over the original SMPL model:
- Hand articulation: Full finger joint modeling with learned grasp and gesture priors
- Facial expression: Comprehensive facial muscle and feature point modeling
- Gender modeling: Explicit male/female/neutral body shape variations
- Improved accuracy: Enhanced joint placement and deformation quality through larger training datasets
The SMPL-X framework represents a paradigm shift from artistic skeletal modeling toward data-driven human representation. This approach proves particularly valuable for applications requiring statistical validity, automated processing, and integration with machine learning pipelines where traditional animation-focused skeletons would introduce systematic biases or workflow incompatibilities.
BVH (Biovision Hierarchy) emerged from Biovision's motion capture systems in the 1990s as a practical solution for storing and transmitting human motion data across heterogeneous animation systems. Unlike skeletal standards designed for specific rendering engines or anatomical accuracy, BVH prioritizes motion data interchange—enabling captured human movement to traverse the boundaries between motion capture systems, animation software, and research applications.
The format's enduring dominance stems from its elegant simplicity: a human-readable text format combining skeletal hierarchy definition with time-series motion data in a single file. This design philosophy reflects the pragmatic requirements of motion capture workflows where data must move between capture systems, cleanup software, animation tools, and final rendering applications—often developed by different vendors with incompatible internal representations.
BVH's architectural constraints emerge from its dual role as both skeletal definition and motion storage format. The skeleton serves primarily as a framework for motion data rather than a comprehensive anatomical model, resulting in joint hierarchies optimized for motion capture fidelity rather than anatomical completeness or real-time performance.
_____ ___ _
| _ ) \ / / || |
| _ \\ V /| __ |
|___/ \_/ |_||_|
Hips
├─ Spine
│ ├─ Spine1 (Chest)
│ ├─ Neck
│ │ └─ Head
│ ├─ LeftShoulder
│ │ └─ LeftArm
│ │ └─ LeftForeArm
│ │ └─ LeftHand
│ │ ├─ LeftHandIndex1 (optional)
│ │ │ └─ LeftHandIndex2 (optional)
│ │ │ └─ LeftHandIndex3 (optional)
│ │ ├─ LeftHandMiddle1 (optional)
│ │ │ └─ LeftHandMiddle2 (optional)
│ │ │ └─ LeftHandMiddle3 (optional)
│ │ ├─ LeftHandRing1 (optional)
│ │ │ └─ LeftHandRing2 (optional)
│ │ │ └─ LeftHandRing3 (optional)
│ │ └─ LeftHandPinky1 (optional)
│ │ └─ LeftHandPinky2 (optional)
│ │ └─ LeftHandPinky3 (optional)
│ └─ RightShoulder
│ └─ RightArm
│ └─ RightForeArm
│ └─ RightHand
│ ├─ RightHandIndex1 (optional)
│ │ └─ RightHandIndex2 (optional)
│ │ └─ RightHandIndex3 (optional)
│ ├─ RightHandMiddle1 (optional)
│ │ └─ RightHandMiddle2 (optional)
│ │ └─ RightHandMiddle3 (optional)
│ ├─ RightHandRing1 (optional)
│ │ └─ RightHandRing2 (optional)
│ │ └─ RightHandRing3 (optional)
│ └─ RightHandPinky1 (optional)
│ └─ RightHandPinky2 (optional)
│ └─ RightHandPinky3 (optional)
├─ LeftUpLeg
│ └─ LeftLeg
│ └─ LeftFoot
│ └─ LeftToeBase (optional)
└─ RightUpLeg
└─ RightLeg
└─ RightFoot
└─ RightToeBase (optional)
Joint Count: Variable (typically 15-57 joints depending on capture system complexity)
Hierarchical Depth: Maximum 9.
Distinctive Characteristics:
- Motion-centric design: Skeletal structure optimized for motion data storage rather than anatomical accuracy
- Human-readable format: Plain text representation enabling manual inspection and modification
- Flexible naming: No standardized joint nomenclature—naming conventions vary across capture systems and content creators
- Channel specification: Explicit declaration of transformation channels per joint (position, rotation order, active degrees of freedom)
Technical Constraints:
- Root joint mobility: Typically only root joint (Hips) carries translation channels; all others rotation-only
- Rotation order declaration: Per-joint specification of Euler rotation order (XYZ, ZXY, etc.) preventing interpretation ambiguity
- Frame-rate dependency: Motion data tied to specific temporal sampling rates
- Unit ambiguity: No standardized length units—common variations include centimeters, meters, and inches
Motion Capture Integration:
BVH's design addresses practical motion capture workflow requirements:
- Capture system agnostic: Compatible with diverse motion capture hardware and software systems
- Post-processing friendly: Text format enables scripted batch processing and automated cleanup
- Animation software compatibility: Widespread import support across commercial and open-source animation tools
- Research accessibility: Simple format structure facilitates academic motion analysis applications
Format Specification Flexibility:
BVH accommodates significant variation in implementation:
- Joint naming freedom: No enforced nomenclature enables capture-system-specific conventions
- Hierarchical variation: Skeletal depth and complexity adapted to capture system capabilities
- Channel configuration: Selective joint channel activation optimizes file size and processing efficiency
- Extension mechanisms: Format supports additional metadata and custom channel types
Cross-Format Mapping Considerations:
BVH's flexibility creates both advantages and challenges for cross-format conversion:
Strengths:
- Widespread compatibility: Near-universal import support across animation and analysis tools
- Motion preservation: Primary focus on temporal data maintains essential movement information
- Processing accessibility: Text format enables custom parsing and conversion tools
Challenges:
- Naming inconsistency: Variable joint nomenclature requires intelligent mapping algorithms
- Skeletal variation: Non-standard hierarchies complicate automated retargeting
- Unit ambiguity: Undeclared measurement units cause scaling inconsistencies
- Missing semantics: Lack of joint role specification hampers automated processing
Industry Adoption Patterns:
BVH's adoption reflects its practical utility across diverse domains:
- Motion capture studios: Industry standard for motion data delivery and archival
- Game development: Common format for importing mocap data into game engines
- Film and television: Intermediate format for motion data exchange between departments
- Academic research: Accessible format for biomechanical analysis and human movement studies
- Online repositories: Standard format for public motion capture datasets and libraries
File Structure Architecture:
BVH's bipartite structure reflects its dual functionality:
- HIERARCHY section: Defines skeletal structure, joint names, parent-child relationships, and channel specifications
- MOTION section: Contains frame count, frame time, and time-series transformation data
- Self-contained design: Single file contains both skeletal definition and complete motion sequence
- Scalable representation: Format accommodates simple marker-based captures through complex multi-actor scenes
Legacy and Evolution:
BVH's influence extends beyond its original motion capture domain:
- Format precedent: Established patterns for motion data representation and storage
- Tool ecosystem: Extensive third-party utilities for conversion, analysis, and manipulation
- Research foundation: Enabled large-scale human motion analysis through accessible data format
- Standardization attempts: Various efforts to formalize BVH variants while maintaining backward compatibility
Performance Characteristics:
The format's design balances functionality with practical constraints:
- Parse complexity: Simple text structure enables rapid parsing and validation
- File size efficiency: Compact representation for long motion sequences
- Memory requirements: Streaming-friendly format supports large motion datasets
- Modification accessibility: Text-based editing enables manual motion adjustment and cleanup
The BVH format represents a pragmatic approach to motion data interchange—prioritizing practical utility and broad compatibility over theoretical completeness or optimal performance. This design philosophy has enabled BVH to serve as the de facto standard for motion capture data exchange across decades of technological evolution, demonstrating the enduring value of simple, flexible formats in complex production workflows.
ASF/AMC (Acclaim Skeleton File/Acclaim Motion Capture) represents the academic research community's approach to motion capture data standardization, emerging from Carnegie Mellon University's Graphics Lab and the broader computer graphics research ecosystem of the late 1990s. Unlike commercially-driven formats that prioritize workflow compatibility, ASF/AMC was designed to support rigorous scientific analysis of human movement with explicit emphasis on reproducibility, precision, and mathematical consistency.
The format's architectural foundation reflects academic research requirements: complete specification of skeletal parameters, explicit degrees of freedom declaration, and separation of anatomical structure from temporal motion data. This design philosophy enables precise control over biomechanical modeling parameters while maintaining the mathematical rigor necessary for quantitative motion analysis and cross-study comparison.
ASF/AMC's influence extends far beyond its original research context through the CMU Graphics Lab Motion Capture Database—one of the largest publicly available human motion datasets. This repository established ASF/AMC as the de facto standard for academic motion analysis, biomechanical research, and algorithm development where mathematical precision takes precedence over production workflow efficiency.
_ ___ ___ ___ __ __ ___
/_\ / __| __/ /_\ | \/ |/ __|
/ _ \\__ \ _/ / _ \| |\/| | (__
/_/ \_\___/_/_/_/ \_\_| |_|\___|
pelvis
├─ lfemur
│ └─ ltibia
│ └─ lfoot
│ └─ ltoes (optional)
├─ rfemur
│ └─ rtibia
│ └─ rfoot
│ └─ rtoes (optional)
└─ lowerback
└─ upperback
└─ thorax
├─ lowerneck
│ └─ upperneck
│ └─ head
├─ lclavicle
│ └─ lhumerus
│ └─ lradius
│ └─ lwrist
│ └─ lhand
│ ├─ lthumb1 (optional)
│ │ └─ lthumb2 (optional)
│ │ └─ lthumb3 (optional)
│ ├─ lindex1 (optional)
│ │ └─ lindex2 (optional)
│ │ └─ lindex3 (optional)
│ ├─ lmiddle1 (optional)
│ │ └─ lmiddle2 (optional)
│ │ └─ lmiddle3 (optional)
│ ├─ lring1 (optional)
│ │ └─ lring2 (optional)
│ │ └─ lring3 (optional)
│ └─ lpinky1 (optional)
│ └─ lpinky2 (optional)
│ └─ lpinky3 (optional)
└─ rclavicle
└─ rhumerus
└─ rradius
└─ rwrist
└─ rhand
├─ rthumb1 (optional)
│ └─ rthumb2 (optional)
│ └─ rthumb3 (optional)
├─ rindex1 (optional)
│ └─ rindex2 (optional)
│ └─ rindex3 (optional)
├─ rmiddle1 (optional)
│ └─ rmiddle2 (optional)
│ └─ rmiddle3 (optional)
├─ rring1 (optional)
│ └─ rring2 (optional)
│ └─ rring3 (optional)
└─ rpinky1 (optional)
└─ rpinky2 (optional)
└─ rpinky3 (optional)
Joint Count: Variable (typically 29-31 joints in canonical CMU implementation)
Hierarchical Depth: Maximum 14
Distinctive Characteristics:
- Explicit parameter specification: Complete declaration of joint axes, degrees of freedom, bone lengths, and coordinate systems within ASF skeleton definition
- Mathematical precision: Floating-point specification of all geometric parameters enabling reproducible scientific analysis
- Standardized nomenclature: Consistent anatomical naming conventions derived from biomechanical literature
- Separated concerns: ASF defines static skeletal structure; AMC contains only temporal motion data
Technical Constraints:
- Unit standardization: Explicit length units (typically inches) and angle units (degrees) declared in ASF header
- Coordinate system definition: Right-handed coordinate system with explicit axis orientations per joint
- DOF declaration: Per-joint specification of active degrees of freedom (rx, ry, rz, tx, ty, tz) with order significance
- Hierarchical relationships: Explicit parent-child bone relationships with transformation inheritance rules
Academic Research Framework:
ASF/AMC's design reflects scientific methodology requirements:
- Reproducibility: Complete parameter specification enables exact recreation of skeletal models across research groups
- Quantitative analysis: Precise geometric definitions support biomechanical calculations and statistical analysis
- Cross-study comparison: Standardized skeletal parameters facilitate meta-analysis and dataset aggregation
- Algorithm validation: Mathematical consistency enables systematic evaluation of motion processing algorithms
Format Specification Rigor:
ASF files provide comprehensive skeletal definition through structured sections:
- Units declaration: Explicit specification of length and angle measurement units
- Documentation: Text-based format supports extensive annotation and metadata
- Root definition: Complete specification of root joint properties and coordinate system
- Bone hierarchy: Systematic declaration of parent-child relationships and transformation parameters
- Axis definitions: Explicit local coordinate systems for each joint with rotation axis specification
Cross-Format Mapping Considerations:
ASF/AMC's academic precision creates specific advantages and challenges:
Strengths:
- Parameter completeness: Comprehensive skeletal specification eliminates ambiguity in cross-format conversion
- Mathematical consistency: Precise geometric definitions enable accurate transformation calculations
- Documentation quality: Text-based format supports detailed annotation and metadata preservation
Challenges:
- Format complexity: Complete parameter specification requires sophisticated parsing and validation
- Academic naming: Biomechanical nomenclature may require translation for production workflows
- Processing overhead: Comprehensive validation and parameter checking increases computational requirements
CMU Database Legacy:
The CMU Graphics Lab Motion Capture Database established ASF/AMC's lasting influence:
- Dataset standardization: Provided consistent skeletal model across thousands of motion sequences
- Research enablement: Accessible format facilitated widespread academic adoption and algorithm development
- Benchmark establishment: Common reference implementation for motion analysis algorithm evaluation
- Educational impact: Standard dataset for computer graphics and biomechanics coursework
Scientific Application Domains:
ASF/AMC's precision makes it particularly valuable for research applications:
- Biomechanical analysis: Joint angle calculations, kinematic analysis, and movement pattern studies
- Algorithm development: Motion processing, recognition, and synthesis algorithm validation
- Medical applications: Gait analysis, rehabilitation monitoring, and movement disorder studies
- Sports science: Athletic performance analysis and technique optimization
- Human factors research: Ergonomic analysis and workspace design studies
Implementation Considerations:
The format's academic origins influence implementation requirements:
- Parser complexity: Complete ASF specification requires comprehensive parsing capabilities
- Validation requirements: Academic applications demand rigorous data validation and error checking
- Precision maintenance: Floating-point calculations must preserve numerical accuracy through processing pipelines
- Metadata preservation: Research applications require maintenance of annotation and documentation data
Evolution and Standardization:
ASF/AMC influenced subsequent motion capture format development:
- Parameter specification patterns: Established precedent for comprehensive skeletal definition
- Academic format adoption: Demonstrated value of research-oriented format design
- Cross-platform compatibility: Proved feasibility of platform-independent motion data exchange
- Open dataset model: Pioneered public motion capture data distribution for research purposes
Performance vs. Precision Trade-offs:
ASF/AMC's design prioritizes accuracy over efficiency:
- Parse overhead: Complete parameter validation increases loading times compared to simpler formats
- Memory requirements: Comprehensive skeletal specification increases memory footprint
- Processing complexity: Mathematical precision requirements may impact real-time performance
- Storage efficiency: Text-based format with extensive metadata creates larger file sizes
The ASF/AMC standard represents a research-first approach to motion capture data representation—prioritizing mathematical rigor, reproducibility, and scientific validity over production workflow optimization. This design philosophy has enabled decades of quantitative human motion research while establishing format design patterns that influence contemporary motion capture standards across both academic and commercial domains.
Mixamo emerged from Adobe's acquisition of the automated animation company Mixamo, Inc., representing a paradigm shift from traditional motion capture workflows toward automated character animation and cross-rig retargeting. Unlike motion capture formats that prioritize data preservation or skeletal standards that emphasize anatomical accuracy, Mixamo's approach centers on practical animation production—enabling rapid character animation through automated rigging and motion transfer across arbitrary skeletal structures.
The platform's architectural foundation reflects cloud-based animation service requirements: skeletal normalization that accommodates diverse input character models while maintaining consistent output quality. This design philosophy addresses the fragmentation in character rigging practices where every 3D artist or studio develops custom skeletal conventions, creating barriers to animation reuse and cross-project compatibility.
Mixamo's influence extends beyond its direct service offerings through its role in democratizing character animation. By automating the traditionally complex processes of rigging and motion retargeting, Mixamo enabled independent developers, small studios, and non-specialists to access professional-quality character animation without extensive technical animation expertise.
__ __ _
| \/ (_)_ ____ _ _ __ ___
| |\/| | \ \ / _` | ' \/ _ \
|_| |_|_/_\_\__,_|_|_|_\___/
Hips
├─ Spine
│ └─ Spine1
│ └─ Spine2
│ ├─ Neck
│ │ └─ Head
│ │ ├─ LeftEye (optional)
│ │ └─ RightEye (optional)
│ ├─ LeftShoulder
│ │ └─ LeftArm
│ │ └─ LeftForeArm
│ │ └─ LeftHand
│ │ ├─ LeftHandThumb1 (optional)
│ │ ├─ LeftHandIndex1 (optional)
│ │ ├─ LeftHandMiddle1 (optional)
│ │ ├─ LeftHandRing1 (optional)
│ │ └─ LeftHandPinky1 (optional)
│ └─ RightShoulder
│ └─ RightArm
│ └─ RightForeArm
│ └─ RightHand
│ ├─ RightHandThumb1 (optional)
│ ├─ RightHandIndex1 (optional)
│ ├─ RightHandMiddle1 (optional)
│ ├─ RightHandRing1 (optional)
│ └─ RightHandPinky1 (optional)
├─ LeftUpLeg
│ └─ LeftLeg
│ └─ LeftFoot
│ └─ LeftToeBase (optional)
└─ RightUpLeg
└─ RightLeg
└─ RightFoot
└─ RightToeBase (optional)
Joint Count: Variable (typically 65-85 joints depending on character complexity and optional finger detail)
Hierarchical Depth: Maximum 9
Distinctive Characteristics:
- Retargeting optimization: Skeletal structure designed to facilitate automated motion transfer across diverse character rigs
- Production-friendly naming: Joint nomenclature balances technical precision with artist accessibility
- Scalable complexity: Optional joint categories accommodate both simple game characters and detailed cinematic rigs
- Cloud service integration: Skeletal definition optimized for automated processing and batch animation workflows
Technical Constraints:
- Retargeting compatibility: Joint placement and naming conventions optimized for cross-rig motion transfer algorithms
- Coordinate system: Follows industry-standard right-handed Y-up conventions for broad software compatibility
- Animation-centric design: Skeletal topology prioritizes animation quality over anatomical accuracy
- Batch processing optimization: Structure designed for automated rigging and animation application workflows
Automated Retargeting Framework:
Mixamo's core innovation lies in its automated motion transfer capabilities:
- Skeletal normalization: Incoming character rigs mapped to standardized skeletal representation
- Proportional adaptation: Motion data scaled and adapted to accommodate character proportion variations
- Quality preservation: Retargeting algorithms maintain motion characteristics across diverse skeletal topologies
- Real-time processing: Cloud-based service delivers animation results within minutes rather than hours
Cross-Format Mapping Considerations:
Mixamo's service-oriented design creates distinct mapping characteristics:
Strengths:
- Broad compatibility: Skeletal structure accommodates diverse input character formats
- Production integration: Joint naming and hierarchy align with common animation software conventions
- Quality consistency: Automated processing ensures reliable output across varied input quality
Challenges:
- Service dependency: Skeletal processing tied to Adobe's cloud infrastructure rather than open specifications
- Limited customization: Automated workflows may not accommodate specialized rigging requirements
- Format lock-in: Proprietary processing algorithms create dependencies on Mixamo ecosystem
Production Workflow Integration:
Mixamo addresses practical animation production requirements:
- Rapid prototyping: Automated rigging enables quick character animation testing and iteration
- Asset scaling: Service model supports projects requiring large numbers of animated characters
- Skill democratization: Automated workflows reduce barriers for non-specialist animators
- Pipeline integration: API access enables integration with existing production tools and workflows
Character Rig Normalization:
The platform's approach to skeletal standardization reflects production realities:
- Rig diversity accommodation: Processing algorithms handle common variations in character rigging practices
- Quality assessment: Automated evaluation of input rig suitability for motion retargeting
- Correction algorithms: Automatic repair of common rigging issues that would prevent successful animation
- Fallback strategies: Graceful degradation when input rigs exceed processing capabilities
Industry Impact and Adoption:
Mixamo's influence on character animation practices:
- Workflow transformation: Shifted animation acquisition from motion capture studios toward automated services
- Independent development enablement: Provided access to professional animation libraries for small-scale projects
- Standard establishment: Influenced skeletal naming conventions and rigging practices across the industry
- Technology advancement: Drove development of automated rigging and retargeting technologies
Service Architecture Considerations:
Cloud-based delivery creates specific technical characteristics:
- Processing optimization: Skeletal structure optimized for server-side batch processing rather than real-time manipulation
- Quality standardization: Consistent output quality across diverse input character variations
- Scalability requirements: Architecture designed to handle thousands of simultaneous animation requests
- Version consistency: Centralized processing ensures consistent results across client applications
Educational and Accessibility Impact:
Mixamo's democratization of character animation:
- Learning acceleration: Simplified workflows enable faster skill development for new animators
- Prototype enablement: Rapid animation testing supports iterative character and game design
- Resource accessibility: Professional-quality animations available to resource-constrained projects
- Technique standardization: Common skeletal conventions reduce learning curve for cross-project collaboration
Limitations and Considerations:
Service-based approach creates inherent constraints:
- Customization boundaries: Automated processing may not accommodate highly specialized rigging requirements
- Creative control: Service model limits fine-grained artistic control over animation details
- Dependency risks: Cloud service dependency creates vulnerability to service changes or discontinuation
- Processing constraints: Batch processing model may not suit interactive or real-time animation requirements
Evolution and Ecosystem:
Mixamo's development reflects broader industry trends:
- Automation adoption: Demonstrates industry shift toward automated content generation tools
- Service integration: Model for cloud-based creative services within larger software ecosystems
- Community impact: Influenced open-source alternatives and competing automated animation services
- Technology transfer: Techniques and approaches adapted by other animation software platforms
The Mixamo standard represents a service-oriented approach to character animation—prioritizing practical production utility and accessibility over theoretical completeness or maximum technical control. This design philosophy has democratized access to professional character animation while establishing skeletal conventions that balance automation requirements with artist workflow integration.
The Unreal Engine Mannequin represents Epic Games' standardized approach to humanoid character representation within their game engine ecosystem. Emerging from decades of game development experience and refined through multiple engine generations, the Mannequin skeleton prioritizes real-time performance, animation system integration, and production scalability across diverse game genres and platforms.
Unlike academic or research-oriented standards that emphasize theoretical completeness, the Mannequin design reflects pragmatic game development requirements: predictable performance characteristics, robust deformation quality, and seamless integration with Unreal's animation blueprint system. This approach addresses the fundamental challenge of game development where character systems must maintain consistent performance across varied hardware configurations while supporting complex gameplay interactions.
The skeleton's architectural foundation incorporates lessons learned from AAA game production, where character rigs must accommodate both cinematic-quality cutscenes and real-time gameplay scenarios. This dual requirement drives design decisions around joint placement, deformation strategies, and optional complexity tiers that can be scaled based on performance budgets and visual fidelity requirements.
_ _ ___ ____ __ _
| | | | __| / / \/ |__ _ _ _ _ _ ___ __ _ _ _(_)_ _
| |_| | _| / /| |\/| / _` | ' \| ' \/ -_) _` | || | | ' \
\___/|___/_/ |_| |_\__,_|_||_|_||_\___\__, |\_,_|_|_||_|
|_|
Root (Pelvis)
├─ Spine_01
│ ├─ Spine_02
│ │ ├─ Spine_03
│ │ │ ├─ Neck_01
│ │ │ │ └─ Head
│ │ │ │ ├─ Eye_L (optional)
│ │ │ │ └─ Eye_R (optional)
│ │ │ ├─ Clavicle_L
│ │ │ │ └─ UpperArm_L
│ │ │ │ └─ LowerArm_L
│ │ │ │ └─ Hand_L
│ │ │ │ └─ Fingers (optional / twist bones exist)
│ │ │ └─ Clavicle_R
│ │ │ └─ UpperArm_R
│ │ │ └─ LowerArm_R
│ │ │ └─ Hand_R
│ │ │ └─ Fingers (optional / twist bones)
├─ Thigh_L
│ └─ Calf_L
│ └─ Foot_L
│ └─ Toe_L (optional)
└─ Thigh_R
└─ Calf_R
└─ Foot_R
└─ Toe_R (optional)
Joint Count: Variable (31 core joints + optional twist bones and facial features, typically 40-60 total)
Hierarchical Depth: Maximum 9
Distinctive Characteristics:
- Performance optimization: Joint count and hierarchy designed for real-time deformation with predictable GPU skinning costs
- Twist bone integration: Optional intermediate joints for enhanced deformation quality without base skeleton modification
- Animation Blueprint compatibility: Joint naming and structure optimized for Unreal's visual scripting animation system
- Scalable complexity: Modular approach enables complexity adjustment based on platform performance requirements
Technical Constraints:
- Real-time performance: Skeletal structure constrained by frame-rate requirements across target hardware platforms
- GPU skinning optimization: Joint placement and weighting designed for efficient vertex shader processing
- Memory alignment: Bone data structures optimized for cache performance and memory bandwidth utilization
- Platform scalability: Architecture accommodates mobile devices through high-end PC and console systems
Game Engine Integration Framework:
The Mannequin's design reflects deep integration with Unreal Engine systems:
- Animation Blueprint compatibility: Joint hierarchy and naming conventions align with visual scripting requirements
- IK system optimization: Bone placement and constraints designed for inverse kinematics solver efficiency
- Physics integration: Skeletal structure supports physics-based animation and ragdoll simulation
- LOD system compatibility: Hierarchical design enables level-of-detail reduction for distant characters
Deformation Quality Strategies:
UE Mannequin addresses real-time deformation challenges through systematic design choices:
- Twist bone implementation: Optional intermediate joints improve limb deformation without impacting base skeleton
- Strategic joint placement: Bone positions optimized for natural deformation under typical game animation constraints
- Corrective blendshapes: Integration points for mesh-based deformation corrections where skeletal deformation proves insufficient
- Performance tiers: Scalable complexity enables quality adjustment based on rendering budget allocation
Cross-Format Mapping Considerations:
The Mannequin's game-centric design creates specific mapping characteristics:
Strengths:
- Production validation: Extensive use in shipped games provides robust real-world validation
- Performance predictability: Well-defined computational costs enable accurate performance budgeting
- Tool integration: Native support within Unreal ecosystem reduces conversion overhead
Challenges:
- Platform specificity: Design optimizations may not translate effectively to other engine environments
- Naming conventions: Game-oriented nomenclature may require translation for non-gaming applications
- Performance constraints: Real-time limitations may exclude features required for offline rendering applications
Production Workflow Optimization:
The skeleton addresses practical game development requirements:
- Asset pipeline integration: Skeletal structure designed for efficient import from common 3D content creation tools
- Animation retargeting: Joint hierarchy enables automated motion transfer between characters using Unreal's retargeting system
- Modular character assembly: Bone structure supports component-based character construction with interchangeable parts
- Collaborative development: Standardized skeleton enables parallel work across multiple team members and disciplines
Performance Characteristics:
Real-time constraints drive specific technical optimizations:
- Bone count limits: Joint quantity balanced against skinning performance on target hardware configurations
- Transform hierarchy depth: Skeletal depth constrained by transformation calculation overhead
- Memory footprint: Bone data structures sized for efficient memory utilization across platform variations
- Update frequency: Skeletal animation designed for consistent performance at target frame rates (60Hz, 120Hz)
Platform Adaptation Strategies:
The Mannequin accommodates diverse hardware capabilities through systematic scaling:
- Mobile optimization: Reduced joint counts and simplified deformation for resource-constrained devices
- Console targeting: Full skeletal complexity with twist bones and corrective systems for fixed hardware platforms
- PC scalability: Variable complexity based on hardware detection and user quality settings
- VR considerations: Specialized optimizations for high frame rate requirements and close-up character inspection
Industry Influence and Adoption:
UE Mannequin's impact extends beyond Epic Games' immediate ecosystem:
- Standard establishment: Influenced skeletal conventions across game development community
- Tool compatibility: Third-party tools developed compatibility with Mannequin conventions and workflows
- Educational adoption: Used as teaching reference for game character rigging and animation courses
- Cross-engine inspiration: Design principles adapted by other game engines and real-time rendering systems
Evolution Through Engine Versions:
The Mannequin has evolved alongside Unreal Engine development:
- Performance optimization: Successive versions refined for improved real-time performance
- Feature expansion: Additional optional joints and systems added while maintaining backward compatibility
- Platform adaptation: Modifications to accommodate new gaming platforms and hardware architectures
- Community feedback: User community input influenced naming conventions, joint placement, and workflow optimizations
Limitations and Design Trade-offs:
Real-time constraints create inherent limitations:
- Anatomical accuracy: Game performance requirements may conflict with anatomical precision
- Artistic flexibility: Standardization limits custom rigging approaches for specific character types
- Complexity ceiling: Performance constraints cap maximum achievable detail level
- Platform dependencies: Optimizations may not transfer effectively to non-Unreal environments
The Unreal Engine Mannequin represents a performance-first approach to humanoid skeletal design—prioritizing real-time efficiency and game development workflow integration over theoretical completeness or maximum expressive detail. This design philosophy has established the Mannequin as a de facto standard for game character development while influencing skeletal design patterns across the broader real-time rendering community.
Unity's Mecanim represents a paradigmatic shift from skeletal-structure-based animation systems toward semantic role-based character representation. Unlike traditional approaches that require matching bone hierarchies and naming conventions, Mecanim abstracts humanoid animation through a standardized Avatar system that maps arbitrary skeletal rigs to canonical humanoid roles, enabling automatic animation retargeting across disparate character models.
This architectural approach emerged from Unity Technologies' recognition that game development teams consistently struggled with animation reuse across different character rigs. Rather than enforcing a specific skeletal standard, Mecanim provides a semantic layer that translates between diverse rigging approaches and a unified animation interface, addressing the practical reality that every character artist develops unique skeletal conventions.
Mecanim's influence extends beyond Unity's immediate ecosystem by establishing semantic animation retargeting as a viable alternative to skeletal standardization. This approach has influenced subsequent animation systems across multiple engines and tools, demonstrating that abstraction layers can provide standardization benefits without imposing rigid structural constraints.
_ _ _ _ ____ __ _
| | | |_ _ (_) |_ _ _ / / \/ |___ __ __ _ _ _ (_)_ __
| |_| | ' \| | _| || |/ /| |\/| / -_) _/ _` | ' \| | ' \
\___/|_||_|_|\__|\_, /_/ |_| |_\___\__\__,_|_||_|_|_|_|_|
|__/
Hips
├─ Spine
│ └─ Chest
│ ├─ UpperChest (optional)
│ ├─ Neck
│ │ └─ Head
│ │ ├─ LeftEye (optional)
│ │ └─ RightEye (optional)
│ ├─ LeftShoulder
│ │ └─ LeftUpperArm
│ │ └─ LeftLowerArm
│ │ └─ LeftHand
│ │ ├─ LeftThumbProximal
│ │ │ └─ LeftThumbIntermediate
│ │ │ └─ LeftThumbDistal
│ │ ├─ LeftIndexProximal
│ │ │ └─ LeftIndexIntermediate
│ │ │ └─ LeftIndexDistal
│ │ ├─ LeftMiddleProximal
│ │ │ └─ LeftMiddleIntermediate
│ │ │ └─ LeftMiddleDistal
│ │ ├─ LeftRingProximal
│ │ │ └─ LeftRingIntermediate
│ │ │ └─ LeftRingDistal
│ │ └─ LeftLittleProximal
│ │ └─ LeftLittleIntermediate
│ │ └─ LeftLittleDistal
│ └─ RightShoulder
│ └─ RightUpperArm
│ └─ RightLowerArm
│ └─ RightHand
│ ├─ RightThumbProximal
│ │ └─ RightThumbIntermediate
│ │ └─ RightThumbDistal
│ ├─ RightIndexProximal
│ │ └─ RightIndexIntermediate
│ │ └─ RightIndexDistal
│ ├─ RightMiddleProximal
│ │ └─ RightMiddleIntermediate
│ │ └─ RightMiddleDistal
│ ├─ RightRingProximal
│ │ └─ RightRingIntermediate
│ │ └─ RightRingDistal
│ └─ RightLittleProximal
│ └─ RightLittleIntermediate
│ └─ RightLittleDistal
├─ LeftUpperLeg
│ └─ LeftLowerLeg
│ └─ LeftFoot
│ └─ LeftToes (optional)
└─ RightUpperLeg
└─ RightLowerLeg
└─ RightFoot
└─ RightToes (optional)
Note: Unity Mecanim's first two thumb bones use medically incorrect terminology.
Joint Count: 55 semantic roles (24 required, 31 optional) mapped to arbitrary source skeletons
Hierarchical Depth: Semantic abstraction independent of source skeletal depth
Distinctive Characteristics:
- Semantic role mapping: Character bones mapped to functional roles (LeftUpperArm, RightHand) rather than enforced naming conventions
- Avatar abstraction: Intermediate representation enables animation sharing across diverse skeletal topologies
- Automatic retargeting: Built-in algorithms handle motion transfer between characters with different proportions and joint configurations
- Editor integration: Visual mapping interface enables artists to assign arbitrary bones to humanoid roles
Technical Constraints:
- Role coverage requirements: Minimum 24 bones must be successfully mapped for Avatar validation
- Proportional limits: Extreme character proportion variations may exceed retargeting algorithm capabilities
- Animation compatibility: Source animations must be authored against humanoid-compatible rigs for optimal retargeting quality
- Performance overhead: Runtime retargeting calculations add computational cost compared to direct skeletal animation
Semantic Mapping Framework:
Mecanim's core innovation lies in role-based skeletal abstraction:
- Functional bone roles: Each semantic role corresponds to specific anatomical function rather than structural requirement
- Mapping tolerance: System accommodates reasonable variations in bone placement and hierarchy organization
- Validation algorithms: Automatic assessment of mapping quality and retargeting suitability
- Fallback strategies: Graceful degradation when optimal bone mappings cannot be established
Cross-Rig Retargeting Capabilities:
The system addresses practical animation reuse requirements:
- Proportion adaptation: Automatic scaling and adjustment for characters with different body proportions
- Missing bone compensation: Animation algorithms interpolate for optional bones not present in target rigs
- Quality preservation: Retargeting maintains essential motion characteristics while adapting to skeletal differences
- Performance scaling: Variable quality settings balance retargeting accuracy against computational cost
Cross-Format Mapping Considerations:
Mecanim's abstraction approach creates unique mapping characteristics:
Strengths:
- Format agnostic: Accepts arbitrary skeletal structures through semantic role assignment
- Animation portability: Enables motion sharing across diverse character types and rigging approaches
- Artist accessibility: Visual mapping interface reduces technical barriers for non-specialist users
Challenges:
- Quality variability: Retargeting results depend heavily on source skeleton appropriateness and mapping accuracy
- Performance overhead: Runtime calculations required for cross-rig animation transfer
- Unity dependency: Semantic mapping system tied to Unity engine rather than open standard
Game Development Workflow Integration:
Mecanim addresses practical game production requirements:
- Asset reuse: Single animation set usable across multiple character models and rigs
- Rapid prototyping: Quick character swapping for gameplay testing and iteration
- Team collaboration: Standardized animation interface enables parallel work across multiple character artists
- Content scaling: Efficient animation production for projects requiring numerous character variations
Avatar Configuration Process:
The system provides structured mapping workflow:
- Automatic detection: Initial bone role assignment based on naming convention analysis and positional heuristics
- Manual refinement: Artist-controlled adjustment of role assignments for optimal retargeting quality
- Validation feedback: Real-time assessment of mapping quality and potential retargeting issues
- Template reuse: Avatar configurations saveable and applicable to similar character rigs
Performance Characteristics:
Semantic abstraction creates specific computational requirements:
- Runtime retargeting: Additional processing overhead for cross-rig animation transfer
- Memory utilization: Avatar data structures and retargeting calculations increase memory requirements
- Optimization strategies: Various performance tiers balance quality against computational cost
- Platform scaling: Retargeting complexity adjusted based on target hardware capabilities
Industry Impact and Adoption:
Mecanim's semantic approach influenced broader animation system development:
- Paradigm establishment: Demonstrated viability of role-based animation systems over structural standardization
- Cross-engine inspiration: Semantic mapping concepts adapted by other game engines and animation tools
- Workflow transformation: Changed game development practices around character animation and asset reuse
- Educational influence: Established semantic retargeting as standard curriculum in game development education
Limitations and Design Trade-offs:
Abstraction benefits come with inherent limitations:
- Quality ceiling: Automatic retargeting cannot match hand-tuned animation for specific character rigs
- Mapping dependencies: System effectiveness depends on source skeleton appropriateness for humanoid representation
- Performance costs: Runtime calculations add overhead compared to direct skeletal animation
- Creative constraints: Semantic roles may not accommodate highly specialized or non-humanoid character types
Evolution and Refinement:
Mecanim has evolved through successive Unity versions:
- Algorithm improvements: Enhanced retargeting quality and performance through iterative refinement
- Workflow optimization: Streamlined Avatar configuration process based on user feedback and usage patterns
- Platform adaptation: Optimizations for mobile devices and emerging platforms like VR and AR
- Community contribution: User feedback and feature requests influenced system development priorities
Educational and Democratization Impact:
The system's accessibility has influenced game development practices:
- Skill barrier reduction: Visual mapping interface enables non-technical artists to configure complex animation systems
- Rapid learning: Standardized workflow reduces time required to master character animation pipelines
- Resource efficiency: Animation reuse capabilities particularly valuable for independent developers and small teams
- Best practice establishment: Semantic mapping approach influenced industry standards for animation system design
The Unity Mecanim system represents an abstraction-first approach to humanoid animation—prioritizing practical workflow benefits and cross-rig compatibility over structural standardization or maximum performance. This design philosophy has democratized advanced animation capabilities while establishing semantic role mapping as a viable alternative to traditional skeletal standardization approaches across the game development industry.
Godot Engine provides a SkeletonProfile class which allows skeletons to be retargeted from rigs found in 3D model files to a structure that the application recognizes for animation, kinematics, and other purposes.
The SkeletonProfileHumanoid class is a specialization of SkeletonProfile that defines a standard humanoid skeleton structure for use within Godot. This class defines names, parenting hierarchy, reference (T-pose) transforms, handles, groups, and whether the bones are required or optional for a valid humanoid skeleton.
The SkeletonProfileHumanoid class exists to serve the same purpose as VRM's humanoid skeleton and Unity Mecanim's humanoid avatar system. In fact, Godot uses the same exact names as VRM, except that VRM bones begin with a lowercase letter, while Godot bones begin with an uppercase letter. The names are also highly similar to Unity Mecanim, except that Godot adds a "Root" bone as the parent of "Hips", and the thumb bones use medically correct terminology.
____ _ _
/ ___| ___ __| | ___ | |_
| | _ / _ \ / _` |/ _ \| __|
| |_| | (_) | (_) | (_) | |_
\____|\___/ \__,_|\___/ \__|
Root
└─ Hips
├─ LeftUpperLeg
│ └─ LeftLowerLeg
│ └─ LeftFoot
│ └─ LeftToes
├─ RightUpperLeg
│ └─ RightLowerLeg
│ └─ RightFoot
│ └─ RightToes
└─ Spine
└─ Chest
└─ UpperChest
├─ Neck
│ └─ Head
│ ├─ Jaw
│ ├─ LeftEye
│ └─ RightEye
├─ LeftShoulder
│ └─ LeftUpperArm
│ └─ LeftLowerArm
│ └─ LeftHand
│ ├─ LeftThumbMetacarpal
│ │ └─ LeftThumbProximal
│ │ └─ LeftThumbDistal
│ ├─ LeftIndexProximal
│ │ └─ LeftIndexIntermediate
│ │ └─ LeftIndexDistal
│ ├─ LeftMiddleProximal
│ │ └─ LeftMiddleIntermediate
│ │ └─ LeftMiddleDistal
│ ├─ LeftRingProximal
│ │ └─ LeftRingIntermediate
│ │ └─ LeftRingDistal
│ └─ LeftLittleProximal
│ └─ LeftLittleIntermediate
│ └─ LeftLittleDistal
└─ RightShoulder
└─ RightUpperArm
└─ RightLowerArm
└─ RightHand
├─ RightThumbMetacarpal
│ └─ RightThumbProximal
│ └─ RightThumbDistal
├─ RightIndexProximal
│ └─ RightIndexIntermediate
│ └─ RightIndexDistal
├─ RightMiddleProximal
│ └─ RightMiddleIntermediate
│ └─ RightMiddleDistal
├─ RightRingProximal
│ └─ RightRingIntermediate
│ └─ RightRingDistal
└─ RightLittleProximal
└─ RightLittleIntermediate
└─ RightLittleDistal
Joint Count: 56 semantic roles (17 required, 39 optional) with 55 of them being humanoid bones, plus 1 optional "Root" bone.
Hierarchical Depth: Restriction that some bones are descendant of others, otherwise semantic abstraction by name.
Distinctive Characteristics:
- Remapping capability: Godot provides a BoneMap class for remapping arbitrary skeletons imported from 3D models into a SkeletonProfile such as SkeletonProfileHumanoid.
Technical Constraints:
- Role coverage requirements: Minimum 17 bones must be successfully mapped for validation.
Strengths:
- Roles inferred by name: Skeletons set up with the recommended bone names can be used as-is without remapping.
- Format agnostic: Prefers skeletons with already conformant names, but accepts arbitrary skeletal structures through bone remapping.
- Animation portability: Enables animation retargeting across skeletons using the same profile, such as the humanoid profile.
- Artist accessibility: Visual mapping interface reduces technical barriers for non-specialist users.
- Similarity: Uses the same bone names as VRM and similar names to Unity Mecanim, easing cross-tool workflows for existing models.
Challenges:
- Editor-centric: Bone remapping tooling is primarily focused on the editor, while runtime imports have less retargeting capabilities.
- Subresource reuse: Godot can only import a single file as one thing. Models containing both animations and an avatar can only be imported as either a scene with embedded animations just for that model, or a library of animations reusable by other models, but not both at the same time.
- Object-oriented: Godot's design is highly object-oriented, with hierarchy items having single purposes, such as being only a bone, only a mesh, only a camera, only a light, and so on. Importing avatars with many "components" attached to a single node is requires generating multiple nodes. 3D artists are recommended to keep different components on separate nodes when creating models to ensure Godot compatibility.
Second Life's humanoid skeleton standard is unique in several ways. Unlike most other standards, it defines ears, wings, a tail, hind legs for taurs/quadruped avatars, and detailed facial bones for lip syncing and expressions.
Second Life's skeleton has gone through 2 iterations, so there are 2 different naming conventions in use: the modern "Bento" skeleton using the "m"-prefixed names (2016), while the legacy "fitted mesh" skeleton uses the all-caps names (pre-2016). The "fitted mesh" names are still used for octahedral "collision volumes", but are not the primary bone names for avatars. The all-caps "collision volume" bones follow the mesh bones because the viewer injects positional offsets relative to the mesh bones, but are never animated separately, nor are any mesh vertices weighted to them, so they are effectively "ghost" bones. Second Life's importer also contains mappings for a few other names such as "rForeArm" and "rShin", which get remapped on import.
____ _ _ _ __
/ ___| ___ ___ ___ _ __ __| | | | (_)/ _| ___
\___ \ / _ \/ __| / _ \| '_ \ / _` | | | | | |_ / _ \
___| | __/ |__ | (_) | | | | (_) | | |___| | _| __/
|____/ \___|\___| \___/|_| |_|\__,_| |_____|_|_| \___|
mPelvis
├─ PELVIS
├─ BUTT
├─ mGroin
├─ mSpine1/2
│ └─ mTorso
│ ├─ BELLY
│ ├─ LEFT_HANDLE
│ ├─ RIGHT_HANDLE
│ ├─ LOWER_BACK
│ └─ mSpine3/4
│ └─ mChest
│ ├─ CHEST
│ ├─ LEFT_PEC
│ ├─ RIGHT_PEC
│ ├─ UPPER_BACK
│ ├─ mWingsRoot
│ │ ├─ mWing1Left
│ │ │ └─ mWing2Left
│ │ │ └─ mWing3Left
│ │ │ ├─ mWing4Left
│ │ │ └─ mWing4FanLeft
│ │ └─ mWing1Right
│ │ └─ mWing2Right
│ │ └─ mWing3Right
│ │ ├─ mWing4Right
│ │ └─ mWing4FanRight
│ ├─ mCollarLeft
│ │ ├─ L_CLAVICLE
│ │ └─ mShoulderLeft
│ │ ├─ L_UPPER_ARM
│ │ └─ mElbowLeft
│ │ ├─ L_LOWER_ARM
│ │ └─ mWristLeft
│ │ ├─ L_HAND
│ │ ├─ mHandThumb1Left
│ │ │ └─ mHandThumb2Left
│ │ │ └─ mHandThumb3Left
│ │ ├─ mHandIndex1Left
│ │ │ └─ mHandIndex2Left
│ │ │ └─ mHandIndex3Left
│ │ ├─ mHandMiddle1Left
│ │ │ └─ mHandMiddle2Left
│ │ │ └─ mHandMiddle3Left
│ │ ├─ mHandRing1Left
│ │ │ └─ mHandRing2Left
│ │ │ └─ mHandRing3Left
│ │ └─ mHandPinky1Left
│ │ └─ mHandPinky2Left
│ │ └─ mHandPinky3Left
│ ├─ mCollarRight
│ │ ├─ R_CLAVICLE
│ │ └─ mShoulderRight
│ │ ├─ R_UPPER_ARM
│ │ └─ mElbowRight
│ │ ├─ R_LOWER_ARM
│ │ └─ mWristRight
│ │ ├─ R_HAND
│ │ ├─ mHandThumb1Right
│ │ │ └─ mHandThumb2Right
│ │ │ └─ mHandThumb3Right
│ │ ├─ mHandIndex1Right
│ │ │ └─ mHandIndex2Right
│ │ │ └─ mHandIndex3Right
│ │ ├─ mHandMiddle1Right
│ │ │ └─ mHandMiddle2Right
│ │ │ └─ mHandMiddle3Right
│ │ ├─ mHandRing1Right
│ │ │ └─ mHandRing2Right
│ │ │ └─ mHandRing3Right
│ │ └─ mHandPinky1Right
│ │ └─ mHandPinky2Right
│ │ └─ mHandPinky3Right
│ └─ mNeck
│ ├─ NECK
│ └─ mHead
│ ├─ HEAD
│ ├─ mSkull
│ ├─ mEyeRight
│ ├─ mEyeLeft
│ └─ mFaceRoot
│ ├─ mFaceJaw
│ │ ├─ mFaceChin
│ │ └─ mFaceTeethLower
│ │ ├─ mFaceLipLowerCenter
│ │ ├─ mFaceLipLowerLeft
│ │ └─ mFaceLipLowerRight
│ │ └─ mFaceTongueBase
│ │ └─ mFaceTongueTip
│ ├─ mFaceEar1Left
│ │ └─ mFaceEar2Left
│ ├─ mFaceEar1Right
│ │ └─ mFaceEar2Right
│ ├─ mFaceCheekLowerLeft
│ ├─ mFaceCheekLowerRight
│ ├─ mFaceCheekUpperLeft
│ ├─ mFaceCheekUpperRight
│ ├─ mFaceEyeAltLeft
│ ├─ mFaceEyeAltRight
│ ├─ mFaceEyebrowCenterLeft
│ ├─ mFaceEyebrowCenterRight
│ ├─ mFaceEyebrowInnerLeft
│ ├─ mFaceEyebrowInnerRight
│ ├─ mFaceEyebrowOuterLeft
│ ├─ mFaceEyebrowOuterRight
│ ├─ mFaceEyecornerInnerLeft
│ ├─ mFaceEyecornerInnerRight
│ ├─ mFaceEyeLidLowerLeft
│ ├─ mFaceEyeLidLowerRight
│ ├─ mFaceEyeLidUpperLeft
│ ├─ mFaceEyeLidUpperRight
│ ├─ mFaceForeheadCenter
│ ├─ mFaceForeheadLeft
│ ├─ mFaceForeheadRight
│ ├─ mFaceJawShaper
│ ├─ mFaceLipUpperCenter
│ ├─ mFaceNoseBase
│ ├─ mFaceNoseBridge
│ ├─ mFaceNoseCenter
│ ├─ mFaceNoseLeft
│ ├─ mFaceNoseRight
│ └─ mFaceTeethUpper
│ ├─ mFaceLipCornerLeft
│ ├─ mFaceLipCornerRight
│ ├─ mFaceLipUpperLeft
│ ├─ mFaceLipUpperRight
│ └─ mFaceLipUpperCenter
├─ mHipLeft
│ ├─ L_UPPER_LEG
│ └─ mKneeLeft
│ ├─ L_LOWER_LEG
│ └─ mAnkleLeft
│ ├─ L_FOOT
│ └─ mFootLeft
│ └─ mToeLeft
├─ mHipRight
│ ├─ R_UPPER_LEG
│ └─ mKneeRight
│ ├─ R_LOWER_LEG
│ └─ mAnkleRight
│ ├─ R_FOOT
│ └─ mFootRight
│ └─ mToeRight
├─ mHindLimbsRoot
│ ├─ mHindLimb1Left
│ │ └─ mHindLimb2Left
│ │ └─ mHindLimb3Left
│ │ └─ mHindLimb4Left
│ └─ mHindLimb1Right
│ └─ mHindLimb2Right
│ └─ mHindLimb3Right
│ └─ mHindLimb4Right
└─ mTail1
└─ mTail2
└─ mTail3
└─ mTail4
└─ mTail5
└─ mTail6
Joint Count: Up to 133 mesh-deforming joint roles (26 required, 107 optional) with 24 collision volume roles for 157 total distinct transforms.
Hierarchical Depth: Restriction that some bones are descendant of others, otherwise semantic abstraction by name.
Strengths:
- Roles inferred by name: Skeletons set up with the recommended bone names can be used as-is without remapping.
- Feature-rich: Supports a wide variety of humanoid and non-humanoid features such as wings, tails, hind legs, and detailed facial bones, allowing for animation of a diverse range of avatar types.
- Runtime customization: Users can adjust a diverse set of "sliders" in-game which modify the avatar in pre-defined ways, such as the size of head/eyes/ears/nose/lips/breasts/butt/belly/foot/etc, the amount of body fat, torso muscles, breast buoyancy, and many more.
- Animation flexibility: The extensive joint set allows for detailed and expressive animations, particularly in facial expressions and lip-syncing.
Challenges:
- Lack of documentation: Official documentation on the skeleton is sparse and incomplete, scattered across various wiki pages, blog posts, form posts, and other community resources. All reference/template skeleton models linked in the wiki are now broken links. The wiki pages are locked for editing, preventing community updates to fix the links or organize/update the documentation.
- Lack of similarity: The naming conventions and choices of bones are unique to Second Life, and are often very different from other humanoid skeleton standards. Content needs to be specifically tailored for Second Life before it can be used, and would need to be converted to be used in other platforms.
- Rotation inconsistency: While most skeletons have their bones pointing in the local +Y direction, Second Life's skeleton does not require this, leading to increased retargeting complexity.
- Legacy baggage: The existence of two different naming conventions in active use creates confusion for new users.
Roblox's humanoid avatar system represents a purpose-built skeletal architecture optimized for the platform's diverse user-generated content ecosystem. The skeleton design balances accessibility for novice creators with sufficient articulation for use in Roblox experiences.
Roblox's built-in facial animation system uses the optional DynamicHead joint as the required root for facial animation. Guidance then indicates that users can create child joints that then can be used to create FACs expressions (as well as other custom animations).
____ _ _
| _ \ ___ | |__ | | _____ __
| |_) / _ \| '_ \| |/ _ \ \/ /
| _ < (_) | |_) | | (_) > <
|_| \_\___/|_.__/|_|\___/_/\_\
Root
└─ HumanoidRootNode
└─ LowerTorso
├─ UpperTorso
│ └─ Head
│ └─ DynamicHead (Opt)
│
├─ LeftUpperArm
│ └─ LeftLowerArm
│ └─ LeftHand
│
├─ RightUpperArm
│ └─ RightLowerArm
│ └─ RightHand
│
├─ LeftUpperLeg
│ └─ LeftLowerLeg
│ └─ LeftFoot
│
└─ RightUpperLeg
└─ RightLowerLeg
└─ RightFoot
Joint Count: 15 core body joints plus optional DynamicHead for facial animation.
Hierarchical Depth: Maximum depth of 6 levels for body (Root → HumanoidRootNode → LowerTorso → UpperTorso → Head → DynamicHead (Opt)).
Strengths:
- Simplified body hierarchy: Minimal core joint count enables efficient real-time animation and broad device compatibility
- Extensible facial animation: DynamicHead serves as the root joint for facial animation, allowing users to define custom child joints that then are used to create FACS expressions
- Platform integration: Native support for Roblox's animation system and facial tracking features
- Accessibility: Simplified structure lowers barriers for user-generated content creation
Limitations:
- No finger articulation: Standard skeleton lacks individual finger bones, limiting hand gesture fidelity
- Limited spine segments: Single torso split limits subtle body language expression
- Platform-specific: Skeleton design is tightly coupled to Roblox platform conventions
- No twist bones: Absence of forearm/upper arm twist correction may cause candy-wrapper deformation
Cross-Platform Considerations:
The Roblox skeleton's unique structure—particularly the LowerTorso/UpperTorso split and animation-driven DynamicHead subsystem—requires careful semantic mapping when retargeting from other standards. Facial animation relies on on optional FACS-based joint animations, where creators define face joints and attributes them to relevant predefined animations. The joints do not have naming/hierarchy requirements other than being a child of the DynamicHead joint (which can technically also be named something else as long as it's mapped in their tooling), enabling creators to define whatever they need/want to enable animations.
Root/HumanoidRootNode/LowerTorso all need to be set to (0,0,0), which makes it so that the root is at the hip rather than below the feet (which is the case for some standards).
The Momentum Human Rig (MHR) represents a high-fidelity humanoid skeleton designed for professional motion capture and animation production. Developed by Meta's Reality Labs Research, the rig features 127 joints with extensive twist bone coverage, detailed foot anatomy, and comprehensive finger articulation; reflecting its use for capturing and reproducing subtle human movement in SAM3D's Body Model.
__ __ _
| \/ | ___ _ __ ___ ___ _ __ | |_ _ _ _ __ ___
| |\/| |/ _ \| '_ ` _ \ / _ \ '_ \| __| | | | '_ ` _ \
| | | | (_) | | | | | | __/ | | | |_| |_| | | | | | |
|_| |_|\___/|_| |_| |_|\___|_| |_|\__|\__,_|_| |_| |_|
root
├─ l_upleg
│ ├─ l_upleg_twist0_proc (twist)
│ ├─ l_upleg_twist1_proc (twist)
│ ├─ l_upleg_twist2_proc (twist)
│ ├─ l_upleg_twist3_proc (twist)
│ ├─ l_upleg_twist4_proc (twist)
│ └─ l_lowleg
│ ├─ l_lowleg_twist1_proc (twist)
│ ├─ l_lowleg_twist2_proc (twist)
│ ├─ l_lowleg_twist3_proc (twist)
│ ├─ l_lowleg_twist4_proc (twist)
│ └─ l_foot
│ └─ l_talocrural
│ └─ l_subtalar
│ └─ l_transversetarsal
│ └─ l_ball
├─ r_upleg
│ ├─ r_upleg_twist0_proc (twist)
│ ├─ r_upleg_twist1_proc (twist)
│ ├─ r_upleg_twist2_proc (twist)
│ ├─ r_upleg_twist3_proc (twist)
│ ├─ r_upleg_twist4_proc (twist)
│ └─ r_lowleg
│ ├─ r_lowleg_twist1_proc (twist)
│ ├─ r_lowleg_twist2_proc (twist)
│ ├─ r_lowleg_twist3_proc (twist)
│ ├─ r_lowleg_twist4_proc (twist)
│ └─ r_foot
│ └─ r_talocrural
│ └─ r_subtalar
│ └─ r_transversetarsal
│ └─ r_ball
└─ c_spine0
└─ c_spine1
└─ c_spine2
└─ c_spine3
├─ l_clavicle
│ └─ l_uparm
│ ├─ l_uparm_twist0_proc (twist)
│ ├─ l_uparm_twist1_proc (twist)
│ ├─ l_uparm_twist2_proc (twist)
│ ├─ l_uparm_twist3_proc (twist)
│ ├─ l_uparm_twist4_proc (twist)
│ └─ l_lowarm
│ ├─ l_lowarm_twist1_proc (twist)
│ ├─ l_lowarm_twist2_proc (twist)
│ ├─ l_lowarm_twist3_proc (twist)
│ ├─ l_lowarm_twist4_proc (twist)
│ └─ l_wrist_twist
│ └─ l_wrist
│ ├─ l_thumb0 → l_thumb1 → l_thumb2 → l_thumb3 → l_thumb_null
│ ├─ l_index1 → l_index2 → l_index3 → l_index_null
│ ├─ l_middle1 → l_middle2 → l_middle3 → l_middle_null
│ ├─ l_ring1 → l_ring2 → l_ring3 → l_ring_null
│ └─ l_pinky0 → l_pinky1 → l_pinky2 → l_pinky3 → l_pinky_null
├─ r_clavicle
│ └─ r_uparm
│ ├─ r_uparm_twist0_proc (twist)
│ ├─ r_uparm_twist1_proc (twist)
│ ├─ r_uparm_twist2_proc (twist)
│ ├─ r_uparm_twist3_proc (twist)
│ ├─ r_uparm_twist4_proc (twist)
│ └─ r_lowarm
│ ├─ r_lowarm_twist1_proc (twist)
│ ├─ r_lowarm_twist2_proc (twist)
│ ├─ r_lowarm_twist3_proc (twist)
│ ├─ r_lowarm_twist4_proc (twist)
│ └─ r_wrist_twist
│ └─ r_wrist
│ ├─ r_thumb0 → r_thumb1 → r_thumb2 → r_thumb3 → r_thumb_null
│ ├─ r_index1 → r_index2 → r_index3 → r_index_null
│ ├─ r_middle1 → r_middle2 → r_middle3 → r_middle_null
│ ├─ r_ring1 → r_ring2 → r_ring3 → r_ring_null
│ └─ r_pinky0 → r_pinky1 → r_pinky2 → r_pinky3 → r_pinky_null
└─ c_neck
├─ c_neck_twist0_proc (twist)
├─ c_neck_twist1_proc (twist)
└─ c_head
├─ l_eye → l_eye_null
├─ r_eye → r_eye_null
├─ c_jaw
│ ├─ c_teeth
│ ├─ c_jaw_null
│ └─ c_tongue0 → c_tongue1 → c_tongue2 → c_tongue3 → c_tongue4
└─ c_head_null
Joint Count: 127 total joints providing comprehensive body, hand, foot, and facial articulation.
Hierarchical Depth: Maximum 12 levels (root → spine chain → arm → wrist → finger chain).
Distinctive Characteristics:
- Extensive twist bone coverage: 5 twist bones per upper leg, 4 per lower leg, 5 per upper arm, and 4 per lower arm eliminate candy-wrapper deformation artifacts
- Anatomically detailed feet: Talocrural, subtalar, and transverse tarsal joints enable accurate foot roll and ground contact animation
- Full finger articulation: Complete finger chains including metacarpals (thumb0, pinky0) with end-effector nulls for IK targeting
- Detailed tongue chain: 5-segment tongue (c_tongue0-4) enables precise lip-sync and speech animation
- Wrist twist bone: Dedicated l/r_wrist_twist joint for improved forearm rotation distribution
Limitations:
- High joint count: 127 joints may exceed performance budgets for real-time applications on resource-constrained platforms
- Complexity overhead: Extensive twist bone chains require careful weight painting and may complicate retargeting workflows
- No facial detail beyond jaw/eyes: Lacks dedicated facial feature bones (eyelids, lips, brow, cheeks) found in some standards like OpenUSD or Second Life
Cross-Platform Considerations:
The twist bones can be collapsed or removed when targeting platforms with simpler requirements, while the core joint positions align well with standard humanoid conventions. The detailed foot structure (talocrural → subtalar → transversetarsal → ball) may require simplification or remapping when targeting standards that use only foot and toe joints.
| CanonicalJoint | OpenUSD | BVH | ASF/AMC | VRM | HAnim | SMPL | SMPL-X | Mixamo | UEMannequin | UnityMecanim | Godot | SecondLife | Roblox | Momentum |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Root (Parent of e.g. Hips) | - | - | - | root | - | - | - | - | - | - | Root | - | Root/HumanoidRootNode | root |
| Hips | Hips | Hips | pelvis | hips | HumanoidRoot | pelvis | pelvis | Hips | Root (Pelvis) | Hips | Hips | mPelvis/PELVIS | LowerTorso | c_spine0 |
| Spine | Torso | Spine | lowerback | spine | lumbosacral | spine1 | spine1 | Spine | Spine_01 | Spine | Spine | mTorso/BELLY | - | c_spine1 |
| Spine1/2/etc | - | - | - | - | - | - | - | - | - | - | - | mSpine1/2/3/4 | - | c_spine1/c_spine2 |
| Chest | Chest | Spine1 / Spine2 | upperback / thorax | chest | thorax | spine2 | spine2 | Spine1 / Spine2 | Spine_02 / Spine_03 | Chest | Chest | mChest/CHEST | UpperTorso | c_spine3 |
| Chest1/2/etc | UpChest | - | - | upperChest | opt | - | - | - | - | UpperChest (opt) | UpperChest | - | - | - |
| Neck | Neck | Neck | lowerneck | neck | neck | neck | neck | Neck | Neck_01 | Neck | Neck | mNeck/NECK | - | c_neck |
| Head | Head | Head | head | head | head | head | head | Head | Head | Head | Head | mHead/HEAD | Head/DynamicHead (Opt) | c_head |
| Head1 | - | - | - | - | - | - | - | - | - | - | - | mSkull | - | - |
| Jaw | - | EndSite | opt | jaw | opt | opt | jaw | opt | opt | Jaw | Jaw | mFaceJaw | - | c_jaw |
| LeftEye | LEye | EndSite | eye_l | leftEye | eyeball_l | - | LEye | opt | Eye_L | LeftEye | LeftEye | mEyeLeft | - | l_eye |
| Left / Right Eyelids | L / R controls x 12 | - | - | - | - | - | - | - | - | - | - | mFaceEyeLid* | - | - |
| LeftEyeTwist | - | - | - | - | - | - | LEyeTwist | - | Eye_L_Twist | - | - | - | - | - |
| RightEye | REye | EndSite | eye_r | rightEye | eyeball_r | - | REye | opt | Eye_R | RightEye | RightEye | mEyeRight | - | r_eye |
| RightEyeTwist | - | - | - | - | - | - | REyeTwist | - | Eye_R_Twist | - | - | - | - | - |
| Nose | Nose | - | - | - | opt | - | Nose | opt | opt | - | - | mFaceNose* | - | - |
| Chin | Chin / LChin / RChin | - | - | - | opt | - | Chin | opt | opt | - | - | mFaceChin | - | - |
| Left / Right Ear | LEar / REar | - | - | - | - | - | - | - | - | - | - | mFaceEar* | - | - |
| LeftCheek | LCheek | - | - | - | opt | - | LCheek | opt | opt | - | - | mFaceCheek(Upper/Lower)Left | - | - |
| RightCheek | RCheek | - | - | - | opt | - | RCheek | opt | opt | - | - | mFaceCheek(Upper/Lower)Right | - | - |
| Mouth | Mouth | - | - | - | opt | - | Mouth | opt | opt | - | - | - | - | - |
| UpperLip | UpLip / LUpLip / RUpLip | - | - | - | opt | - | UpLip | opt | opt | - | - | mFaceLipUpper* | - | - |
| LowerLip | LoLip / LLoLip / RLoLip | - | - | - | opt | - | LoLip | opt | opt | - | - | mFaceLipLower* | - | - |
| LeftLipCorner | LLipCorner | - | - | - | opt | - | LLipCorner | opt | opt | - | - | mFaceLipCornerLeft | - | - |
| RightLipCorner | RLipCorner | - | - | - | opt | - | RLipCorner | opt | opt | - | - | mFaceLipCornerRight | - | - |
| Brow | LBrow / Brow | - | - | - | opt | - | LBrow / RBrow | opt | opt | - | - | mFaceEyebrow* | - | - |
| LeftShoulder | LShldr | LeftShoulder | lclavicle | leftShoulder | clavicle_l | LShldr | LShldr | LeftShoulder | Clavicle_L | LeftShoulder | LeftShoulder | mCollarLeft/L_CLAVICLE | LeftUpperArm | l_clavicle |
| LeftUpperArm | LArm | LeftArm | lhumerus | leftUpperArm | humerus_l | LArm | LArm | LeftArm | UpperArm_L | LeftUpperArm | LeftUpperArm | mShoulderLeft/L_UPPER_ARM | - | l_uparm |
| LeftLowerArm | LElbow | LeftForeArm | lradius | leftLowerArm | radius_l | LForeArm | LForeArm | LeftForeArm | LowerArm_L | LeftLowerArm | LeftLowerArm | mElbowLeft/L_LOWER_ARM | LeftLowerArm | l_lowarm |
| LeftHand | LHand | LeftHand | lwrist | leftHand | hand_l | LHand | LHand | LeftHand | Hand_L | LeftHand | LeftHand | mWristLeft/L_HAND | LeftHand | l_wrist |
| LeftThumbMetacarpal | LThumb | - | lthumb | leftThumbMetacarpal | opt | - | LThumb | LThumb | opt | LeftThumbProximal | LeftThumbMetacarpal | mHandThumb1Left | - | l_thumb0 |
| LeftThumbProximal | LThumbMid | - | - | leftThumbProximal | opt | - | LThumbMid | LThumbMid | opt | LeftThumbIntermediate | LeftThumbProximal | mHandThumb2Left | - | l_thumb1 |
| LeftThumbDistal | LThumbTip | - | - | leftThumbDistal | opt | - | LThumbTip | LThumbTip | opt | LeftThumbDistal | LeftThumbDistal | mHandThumb3Left | - | l_thumb2 |
| LeftThumbTip | LThumbEnd | - | - | - | opt | - | LThumbEnd | LThumbEnd | opt | - | - | - | - | l_thumb_null |
| LeftIndexMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | - |
| LeftIndexProximal | LIndex | - | lindex | leftIndexProximal | opt | - | LIndex | LIndex | opt | LeftIndexProximal | LeftIndexProximal | mHandIndex1Left | - | l_index1 |
| LeftIndexIntermediate | LIndexMid | - | - | leftIndexIntermediate | opt | - | LIndexMid | LIndexMid | opt | LeftIndexIntermediate | LeftIndexIntermediate | mHandIndex2Left | l_index2 | |
| LeftIndexDistal | LIndexTip | - | - | leftIndexDistal | opt | - | LIndexTip | LIndexTip | opt | LeftIndexDistal | LeftIndexDistal | mHandIndex3Left | l_index3 | |
| LeftIndexTip | LIndexEnd | - | - | - | opt | - | LIndexEnd | LIndexEnd | opt | - | - | - | l_index_null | |
| LeftMiddleMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | |
| LeftMiddleProximal | LMiddle | - | - | leftMiddleProximal | opt | - | LMiddle | LMiddle | opt | LeftMiddleProximal | LeftMiddleProximal | mHandMiddle1Left | l_middle1 | |
| LeftMiddleIntermediate | LMiddleMid | - | lmiddle | leftMiddleIntermediate | opt | - | LMiddleMid | LMiddleMid | opt | LeftMiddleIntermediate | LeftMiddleIntermediate | mHandMiddle2Left | l_middle2 | |
| LeftMiddleDistal | LMiddleTip | - | - | leftMiddleDistal | opt | - | LMiddleTip | LMiddleTip | opt | LeftMiddleDistal | LeftMiddleDistal | mHandMiddle3Left | l_middle3 | |
| LeftMiddleTip | LMiddleEnd | - | - | - | opt | - | LMiddleEnd | LMiddleEnd | opt | - | - | - | l_middle_null | |
| LeftRingMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | |
| LeftRingProximal | LRing | - | lring | leftRingProximal | opt | - | LRing | LRing | opt | LeftRingProximal | LeftRingProximal | mHandRing1Left | l_ring1 | |
| LeftRingIntermediate | LRingMid | - | - | leftRingIntermediate | opt | - | LRingMid | LRingMid | opt | LeftRingIntermediate | LeftRingIntermediate | mHandRing2Left | l_ring2 | |
| LeftRingDistal | LRingTip | - | - | leftRingDistal | opt | - | LRingTip | LRingTip | opt | LeftRingDistal | LeftRingDistal | mHandRing3Left | l_ring3 | |
| LeftRingTip | LRingEnd | - | - | - | opt | - | LRingEnd | LRingEnd | opt | - | - | - | l_ring_null | |
| LeftPinkyMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | l_pinky0 | |
| LeftPinkyProximal | LPinky | - | lpinky | leftLittleProximal | opt | - | LPinky | LPinky | opt | LeftLittleProximal | LeftLittleProximal | mHandPinky1Left | l_pinky1 | |
| LeftPinkyIntermediate | LPinkyMid | - | - | leftLittleIntermediate | opt | - | LPinkyMid | LPinkyMid | opt | LeftLittleIntermediate | LeftLittleIntermediate | mHandPinky2Left | l_pinky2 | |
| LeftPinkyDistal | LPinkyTip | - | - | leftLittleDistal | opt | - | LPinkyTip | LPinkyTip | opt | LeftLittleDistal | LeftLittleDistal | mHandPinky3Left | l_pinky3 | |
| LeftPinkyTip | LPinkyEnd | - | - | - | opt | - | LPinkyEnd | LPinkyEnd | opt | - | - | - | l_pinky_null | |
| RightShoulder | RShldr | RightShoulder | rclavicle | rightShoulder | clavicle_r | RShldr | RShldr | RightShoulder | Clavicle_R | RightShoulder | RightShoulder | mCollarRight/R_CLAVICLE | r_clavicle | |
| RightUpperArm | RArm | RightArm | rhumerus | rightUpperArm | humerus_r | RArm | RArm | RightArm | UpperArm_R | RightUpperArm | RightUpperArm | mShoulderRight/R_UPPER_ARM | r_uparm | |
| RightLowerArm | RElbow | RightForeArm | rradius | rightLowerArm | radius_r | RForeArm | RForeArm | RightForeArm | LowerArm_R | RightLowerArm | RightLowerArm | mElbowRight/R_LOWER_ARM | r_lowarm | |
| RightHand | RHand | RightHand | rwrist | rightHand | hand_r | RHand | RHand | RightHand | Hand_R | RightHand | RightHand | mWristRight/R_HAND | r_wrist | |
| RightThumbMetacarpal | RThumb | - | rthumb | rightThumbMetacarpal | opt | - | RThumb | RThumb | opt | RightThumbProximal | RightThumbMetacarpal | mHandThumb1Right | r_thumb0 | |
| RightThumbProximal | RThumbMid | - | - | rightThumbProximal | opt | - | RThumbMid | RThumbMid | opt | RightThumbIntermediate | RightThumbProximal | mHandThumb2Right | r_thumb1 | |
| RightThumbDistal | RThumTip | - | - | rightThumbDistal | opt | - | RThumbTip | RThumbTip | opt | RightThumbDistal | RightThumbDistal | mHandThumb3Right | r_thumb2 | |
| RightThumbTip | RThumEnd | - | - | - | opt | - | RThumbEnd | RThumbEnd | opt | - | - | - | r_thumb_null | |
| RightIndexMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | |
| RightIndexProximal | RIndex | - | rindex | rightIndexProximal | opt | - | RIndex | RIndex | opt | RightIndexProximal | RightIndexProximal | mHandIndex1Right | r_index1 | |
| RightIndexIntermediate | RIndexMid | - | - | rightIndexIntermediate | opt | - | RIndexMid | RIndexMid | opt | RightIndexIntermediate | RightIndexIntermediate | mHandIndex2Right | r_index2 | |
| RightIndexDistal | RIndexTip | - | - | rightIndexDistal | opt | - | RIndexTip | RIndexTip | opt | RightIndexDistal | RightIndexDistal | mHandIndex3Right | r_index3 | |
| RightIndexTip | RIndexEnd | - | - | - | opt | - | RIndexEnd | RIndexEnd | opt | - | - | - | r_index_null | |
| RightMiddleMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | |
| RightMiddleProximal | RMiddle | - | rmiddle | rightMiddleProximal | opt | - | RMiddle | RMiddle | opt | RightMiddleProximal | RightMiddleProximal | mHandMiddle1Right | r_middle1 | |
| RightMiddleIntermediate | RMiddleMid | - | - | rightMiddleIntermediate | opt | - | RMiddleMid | RMiddleMid | opt | RightMiddleIntermediate | RightMiddleIntermediate | mHandMiddle2Right | r_middle2 | |
| RightMiddleDistal | RMiddleTip | - | - | rightMiddleDistal | opt | - | RMiddleTip | RMiddleTip | opt | RightMiddleDistal | RightMiddleDistal | mHandMiddle3Right | r_middle3 | |
| RightMiddleTip | RMiddleEnd | - | - | - | opt | - | RMiddleEnd | RMiddleEnd | opt | - | - | - | r_middle_null | |
| RightRingMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | - | |
| RightRingProximal | RRing | - | rring | rightRingProximal | opt | - | RRing | RRing | opt | RightRingProximal | RightRingProximal | mHandRing1Right | r_ring1 | |
| RightRingIntermediate | RRingMid | - | - | rightRingIntermediate | opt | - | RRingMid | RRingMid | opt | RightRingIntermediate | RightRingIntermediate | mHandRing2Right | r_ring2 | |
| RightRingDistal | RRingTip | - | - | rightRingDistal | opt | - | RRingTip | RRingTip | opt | RightRingDistal | RightRingDistal | mHandRing3Right | r_ring3 | |
| RightRingTip | RRingEnd | - | - | - | opt | - | RRingEnd | RRingEnd | opt | - | - | - | r_ring_null | |
| RightPinkyMetacarpal | - | - | - | - | - | - | - | - | - | - | - | - | r_pinky0 | |
| RightPinkyProximal | RPinky | - | rpinky | rightLittleProximal | opt | - | RPinky | RPinky | opt | RightLittleProximal | RightLittleProximal | mHandPinky1Right | r_pinky1 | |
| RightPinkyIntermediate | RPinkyMid | - | - | rightLittleIntermediate | opt | - | RPinkyMid | RPinkyMid | opt | RightLittleIntermediate | RightLittleIntermediate | mHandPinky2Right | r_pinky2 | |
| RightPinkyDistal | RPinkyTip | - | - | rightLittleDistal | opt | - | RPinkyTip | RPinkyTip | opt | RightLittleDistal | RightLittleDistal | mHandPinky3Right | r_pinky3 | |
| RightPinkyTip | RPinkyEnd | - | - | - | opt | - | RPinkyEnd | RPinkyEnd | opt | - | - | - | r_pinky_null | |
| LeftUpperLeg | LLeg | LeftUpLeg | lfemur | leftUpperLeg | femur_l | LThigh | LThigh | LeftUpLeg | Thigh_L | LeftUpperLeg | LeftUpperLeg | mHipLeft/L_UPPER_LEG | l_upleg | |
| LeftLowerLeg | LKnee | LeftLeg | ltibia | leftLowerLeg | tibia_l | LLeg | LLeg | LeftLeg | Calf_L | LeftLowerLeg | LeftLowerLeg | mKneeLeft/L_LOWER_LEG | l_lowleg | |
| LeftFoot | LFoot | LeftFoot | lfoot | leftFoot | foot_l | LFoot | LFoot | LeftFoot | Foot_L | LeftFoot | LeftFoot | mAnkleLeft/L_FOOT | l_foot | |
| LeftFoot1 | - | - | - | - | - | - | - | - | - | - | - | mFootLeft | l_talocrural | |
| LeftToes | LToes | EndSite | ltoes | leftToes | opt | - | LeftToes | LeftToeBase | Toe_L (opt) | LeftToes (opt) | LeftToes | mToeLeft | l_ball | |
| LeftToesTip | LTip | - | - | - | opt | - | LTip | - | LeftTip (opt) | - | - | - | - | |
| RightUpperLeg | RLeg | RightUpLeg | rfemur | rightUpperLeg | femur_r | RThigh | RThigh | RightUpLeg | Thigh_R | RightUpperLeg | RightUpperLeg | mHipRight/R_UPPER_LEG | r_upleg | |
| RightLowerLeg | RKnee | RightLeg | rtibia | rightLowerLeg | tibia_r | RLeg | RLeg | RightLeg | Calf_R | RightLowerLeg | RightLowerLeg | mKneeRight/R_LOWER_LEG | r_lowleg | |
| RightFoot | RFoot | RightFoot | rfoot | rightFoot | foot_r | RFoot | RFoot | RightFoot | Foot_R | RightFoot | RightFoot | mAnkleRight/R_FOOT | r_foot | |
| RightFoot1 | - | - | - | - | - | - | - | - | - | - | - | mFootRight | r_talocrural | |
| RightToes | RToes | EndSite | rtoes | rightToes | opt | - | - | RightToeBase | Toe_R (opt) | RightToes (opt) | RightToes | mToeRight | r_ball | |
| RightToesTip | RTip | - | - | - | opt | - | RTip | - | RightTip (opt) | - | - | - | - |
The unified mapping table represents a systematic approach to cross-standard semantic correspondence, establishing canonical joint roles that transcend format-specific naming conventions and structural variations. This methodology addresses the fundamental challenge of humanoid skeletal interoperability: while anatomical structure remains consistent across human populations, technical representations diverge significantly based on application domain requirements and historical development contexts.
The canonical joint taxonomy emerges from comparative analysis across all covered standards, identifying semantic commonalities while preserving format-specific distinctions. This approach enables automated mapping algorithms to maintain anatomical consistency during cross-format conversion while respecting the operational constraints that drive each standard's design decisions.
Cross-format correspondence exhibits distinct complexity tiers that reflect fundamental differences in design philosophy and application requirements:
Standards exhibiting strong structural correspondence enable direct one-to-one joint mapping with minimal semantic interpretation. This category includes relationships between production animation standards (OpenUSD, Mixamo) and game engine implementations (UE Mannequin, Unity Mecanim) where similar workflow requirements drive convergent skeletal architectures.
Format pairs requiring systematic nomenclature translation while maintaining hierarchical correspondence. The relationship between BVH and ASF/AMC exemplifies this tier—both serve motion capture applications with similar joint coverage but employ distinct naming conventions reflecting their respective academic versus commercial origins.
Cross-format relationships requiring semantic role interpretation rather than direct structural mapping. Unity Mecanim's relationship to other standards exemplifies this complexity, where arbitrary source skeletons must be mapped to canonical humanoid roles through semantic analysis rather than positional correspondence.
The most complex correspondence tier involving fundamental architectural differences that require algorithmic mediation. SMPL-X relationships to traditional skeletal standards represent this category, where statistical parameter spaces must be converted to explicit joint hierarchies through model evaluation and pose extraction.
Cross-format conversion exhibits systematic asymmetries that reflect the directional nature of information preservation and loss during translation:
Comprehensive standards (OpenUSD, HAnim) generally map successfully to simplified representations through selective joint exclusion and hierarchy flattening. This direction preserves essential anatomical relationships while discarding detail that exceeds target format capabilities.
Conversion from minimal to comprehensive representations requires interpolation or approximation strategies where source data lacks required detail. Motion capture formats (BVH, ASF/AMC) typically provide insufficient facial or finger detail for full OpenUSD compatibility, necessitating procedural generation or artist intervention.
Format pairs with similar complexity but different architectural approaches require sophisticated mapping strategies. VRM-to-Mixamo conversion exemplifies this challenge, where semantic role systems must interface with service-oriented processing workflows through intermediate canonical representations.
Hips
├─ Spine
│ └─ Chest
│ ├─ Neck
│ │ └─ Head
│ │ ├─ Jaw (opt)
│ │ ├─ LeftEye (opt)
│ │ │ └─ LeftEyeTwist (twist)
│ │ ├─ RightEye (opt)
│ │ │ └─ RightEyeTwist (twist)
│ │ ├─ LeftLid (opt)
│ │ ├─ RightLid (opt)
│ │ ├─ LeftEar (opt)
│ │ ├─ RightEar (opt)
│ │ ├─ Nose (opt)
│ │ ├─ Chin (opt)
│ │ ├─ LeftCheek (opt)
│ │ ├─ RightCheek (opt)
│ │ ├─ Mouth (opt)
│ │ │ ├─ UpperLip (opt)
│ │ │ ├─ LowerLip (opt)
│ │ │ ├─ LeftLipCorner (opt)
│ │ │ └─ RightLipCorner (opt)
│ │ └─ Brow (opt)
│ ├─ LeftShoulder
│ │ └─ LeftUpperArm
│ │ └─ LeftLowerArm
│ │ └─ LeftHand
│ │ ├─ LeftThumbMetacarpal (opt)
│ │ │ └─ LeftThumbProximal (opt)
│ │ │ └─ LeftThumbDistal (opt)
│ │ │ └─ LeftThumbTip (opt)
│ │ ├─ LeftIndexMetacarpal (opt / uncommon)
│ │ │ └─ LeftIndexProximal (opt)
│ │ │ └─ LeftIndexIntermediate (opt)
│ │ │ └─ LeftIndexDistal (opt)
│ │ │ └─ LeftIndexTip (opt)
│ │ ├─ LeftMiddleMetacarpal (opt / uncommon)
│ │ │ └─ LeftMiddleProximal (opt)
│ │ │ └─ LeftMiddleIntermediate (opt)
│ │ │ └─ LeftMiddleDistal (opt)
│ │ │ └─ LeftMiddleTip (opt)
│ │ ├─ LeftRingMetacarpal (opt / uncommon)
│ │ │ └─ LeftRingProximal (opt)
│ │ │ └─ LeftRingIntermediate (opt)
│ │ │ └─ LeftRingDistal (opt)
│ │ │ └─ LeftRingTip (opt)
│ │ └─ LeftPinkyMetacarpal (opt / uncommon)
│ │ └─ LeftPinkyProximal (opt)
│ │ └─ LeftPinkyIntermediate (opt)
│ │ └─ LeftPinkyDistal (opt)
│ │ └─ LeftPinkyTip (opt)
│ └─ RightShoulder
│ └─ RightUpperArm
│ └─ RightLowerArm
│ └─ RightHand
│ ├─ RightThumbMetacarpal (opt)
│ │ └─ RightThumbProximal (opt)
│ │ └─ RightThumbDistal (opt)
│ │ └─ RightThumbTip (opt)
│ ├─ RightIndexMetacarpal (opt / uncommon)
│ │ └─ RightIndexProximal (opt)
│ │ └─ RightIndexIntermediate (opt)
│ │ └─ RightIndexDistal (opt)
│ │ └─ RightIndexTip (opt)
│ ├─ RightMiddleMetacarpal (opt / uncommon)
│ │ └─ RightMiddleProximal (opt)
│ │ └─ RightMiddleIntermediate (opt)
│ │ └─ RightMiddleDistal (opt)
│ │ └─ RightMiddleTip (opt)
│ ├─ RightRingMetacarpal (opt / uncommon)
│ │ └─ RightRingProximal (opt)
│ │ └─ RightRingIntermediate (opt)
│ │ └─ RightRingDistal (opt)
│ │ └─ RightRingTip (opt)
│ └─ RightPinkyMetacarpal (opt / uncommon)
│ └─ RightPinkyProximal (opt)
│ └─ RightPinkyIntermediate (opt)
│ └─ RightPinkyDistal (opt)
│ └─ RightPinkyTip (opt)
├─ LeftUpperLeg
│ └─ LeftLowerLeg
│ └─ LeftFoot
│ └─ LeftToes (opt)
│ └─ LeftToesTip (opt)
└─ RightUpperLeg
└─ RightLowerLeg
└─ RightFoot
└─ RightToes (opt)
└─ RightToesTip (opt)
(opt)= optional joint, not present in all skeleton standards(opt / uncommon)= optional joint, not present in most skeleton standards(twist)= twist bone, for improved deformation (UE Mannequin, SMPL-X)- Fingers and toes are fully segmented: metacarpal → proximal → intermediate → distal → tip
- Facial and head joints fully enumerated for optional eyes, jaw, lips, cheeks
- Root: Hips/Pelvis, all translations + rotations occur here
The Reference Canonical Skeleton represents a synthesis approach to humanoid skeletal standardization—incorporating the maximum joint coverage identified across all analyzed standards while maintaining hierarchical coherence and anatomical validity. Unlike standards designed for specific application domains, the canonical skeleton prioritizes comprehensive coverage that enables lossless downward mapping to any target format while providing canonical reference points for cross-format validation and quality assessment.
This architectural approach addresses the fundamental challenge of cross-standard interoperability: no single existing standard provides adequate coverage for all application domains. By synthesizing the collective joint vocabulary across formats, the canonical skeleton serves as a universal translation hub that eliminates the need for direct n-to-n conversion algorithms while providing authoritative semantic definitions for joint correspondence validation.
Joint placement and parent-child relationships follow established anatomical structure rather than format-specific conventions. This approach ensures that the canonical skeleton maintains biomechanical validity regardless of which format-specific subsets are extracted for particular applications.
The anatomical foundation provides objective criteria for resolving conflicts between format-specific joint placements or naming conventions. When standards disagree on hierarchical relationships, anatomical structure provides authoritative resolution that maintains consistency with human skeletal biomechanics.
The canonical skeleton incorporates every distinct joint identified across all analyzed standards, creating a comprehensive vocabulary that accommodates the most detailed requirements from any source format. This approach ensures that no semantic information is lost during conversion operations, enabling high-fidelity round-trip conversions where supported by target formats.
Optional and secondary joints from specialized standards (facial controls from OpenUSD, twist bones from UE Mannequin, statistical joints from SMPL-X) are integrated systematically rather than treated as format-specific extensions. This integration maintains consistent hierarchical relationships while clearly marking joints that may not have correspondence in simplified target formats.
Joint naming follows descriptive conventions that balance anatomical accuracy with technical accessibility. The nomenclature system provides clear semantic correspondence to format-specific naming while avoiding the abbreviations or technical codes that can obscure joint function during cross-format mapping operations.
Bilateral symmetry is maintained through consistent left/right prefixing that enables algorithmic detection of symmetric joint pairs. This symmetry support proves essential for animation retargeting algorithms that rely on bilateral correspondence for motion transfer and adaptation.
The canonical skeleton accommodates the comprehensive facial and finger control requirements of feature animation pipelines while maintaining compatibility with simplified game development workflows. This dual coverage enables projects to scale complexity based on quality requirements without restructuring fundamental skeletal architecture.
Facial joint coverage incorporates the detailed eyelid, lip, and expression controls identified in the OpenUSD exemplar while providing clear mapping relationships to blendshape-based expression systems used in other standards. This hybrid approach supports both joint-based and mesh-based facial animation workflows.
Joint placement and hierarchy design accommodate both marker-based and markerless motion capture systems, ensuring that captured motion data can be applied effectively across the comprehensive joint set. Optional joints are structured to enable graceful degradation when motion capture data provides insufficient detail for full skeleton population.
The hierarchical design supports both dense motion capture (full finger and facial tracking) and simplified capture systems (core body joints only) through systematic joint classification that enables appropriate subset selection based on data availability.
The canonical skeleton maintains compatibility with academic motion analysis requirements through precise joint placement and comprehensive parameter specification. Anatomical accuracy and measurement precision support biomechanical analysis applications while format flexibility accommodates diverse research methodologies.
Statistical validation capabilities enable quantitative assessment of cross-format conversion quality and motion preservation accuracy. This research compatibility ensures that the canonical skeleton can serve as a validation framework for cross-format conversion algorithms and quality assessment methodologies.
The canonical skeleton serves as a platform for developing and validating new cross-format conversion algorithms, semantic mapping strategies, and quality assessment methodologies. This research capability supports continued improvement of cross-format interoperability while providing validation infrastructure for new approaches.
The comprehensive analysis of ten major humanoid skeletal standards reveals a landscape characterized by convergent anatomical foundations but divergent architectural implementations. While all standards address the same underlying human skeletal structure, their technical expressions reflect the distinct operational contexts, performance constraints, and workflow requirements of their respective domains.
Three primary architectural paradigms emerge from this analysis: production-optimized standards (OpenUSD, Mixamo, UE Mannequin) that prioritize expressive capability or performance efficiency; research-validated formats (HAnim, SMPL-X, ASF/AMC) that emphasize anatomical accuracy or statistical validity; and workflow-abstraction systems (Unity Mecanim, VRM) that provide semantic mapping layers for cross-format compatibility. Each paradigm demonstrates systematic trade-offs between competing requirements that cannot be simultaneously optimized within single-purpose implementations.
The unified mapping table analysis demonstrates that cross-format correspondence exhibits predictable complexity patterns ranging from direct structural alignment through semantic translation to paradigmatic transformation. These patterns provide systematic frameworks for developing conversion algorithms and quality assessment methodologies while highlighting the fundamental information asymmetries that constrain conversion fidelity in specific directional mappings.
Current cross-format conversion challenges stem not from technical impossibility but from the absence of comprehensive semantic frameworks that preserve anatomical consistency while accommodating format-specific constraints. The proliferation of ad hoc conversion tools and format-specific workflows reflects this gap rather than inherent incompatibility between humanoid representations.
The Reference Canonical Skeleton Framework provides a systematic approach to resolving these interoperability challenges through synthesis rather than standardization. By incorporating maximum joint coverage from all analyzed standards within anatomically consistent hierarchical structures, the framework enables lossless downward mapping while providing canonical reference points for conversion validation and quality assessment.
This approach challenges the assumption that cross-format compatibility requires universal adoption of single skeletal standards. Instead, comprehensive intermediate representations can provide translation infrastructure that preserves the specialized optimizations driving format-specific design decisions while enabling seamless interoperability across application domains.
The comprehensive analysis demonstrates that humanoid skeletal interoperability represents a solvable technical challenge. The semantic frameworks, mapping methodologies, and synthesis architectures developed through this research provide immediate practical utility and foundations for further work.
CanonicalJoint,OpenUSD,BVH,ASF/AMC,VRM,HAnim,SMPL,SMPL-X,Mixamo,UEMannequin,UnityMecanim,Godot,SecondLife,Roblox,Momentum
Root (Parent of e.g. Hips),-,-,-,root,-,-,-,-,-,-,Root,-,Root/HumanoidRootNode,root
Hips,Hips,Hips,pelvis,hips,HumanoidRoot,pelvis,pelvis,Hips,Root (Pelvis),Hips,Hips,mPelvis/PELVIS,LowerTorso,c_spine0
Spine,Torso,Spine,lowerback,spine,lumbosacral,spine1,spine1,Spine,Spine_01,Spine,Spine,mTorso/BELLY,-,c_spine1
Spine1/2/etc,-,-,-,-,-,-,-,-,-,-,-,mSpine1/2/3/4,-,c_spine1/c_spine2
Chest,Chest,Spine1 / Spine2,upperback / thorax,chest,thorax,spine2,spine2,Spine1 / Spine2,Spine_02 / Spine_03,Chest,Chest,mChest/CHEST,UpperTorso,c_spine3
Chest1/2/etc,UpChest,-,-,upperChest,opt,-,-,-,-,UpperChest (opt),UpperChest,-,-,-
Neck,Neck,Neck,lowerneck,neck,neck,neck,neck,Neck,Neck_01,Neck,Neck,mNeck/NECK,-,c_neck
Head,Head,Head,head,head,head,head,head,Head,Head,Head,Head,mHead/HEAD,Head/DynamicHead (Opt),c_head
Head1,-,-,-,-,-,-,-,-,-,-,-,mSkull,-,-
Jaw,-,EndSite,opt,jaw,opt,opt,jaw,opt,opt,Jaw,Jaw,mFaceJaw,c_jaw
LeftEye,LEye,EndSite,eye_l,leftEye,eyeball_l,-,LEye,opt,Eye_L,LeftEye,LeftEye,mEyeLeft,l_eye
Left / Right Eyelids,L / R controls x 12,-,-,-,-,-,-,-,-,-,-,mFaceEyeLid*,-
LeftEyeTwist,-,-,-,-,-,-,LEyeTwist,-,Eye_L_Twist,-,-,-,-
RightEye,REye,EndSite,eye_r,rightEye,eyeball_r,-,REye,opt,Eye_R,RightEye,RightEye,mEyeRight,r_eye
RightEyeTwist,-,-,-,-,-,-,REyeTwist,-,Eye_R_Twist,-,-,-,-
Nose,Nose,-,-,-,opt,-,Nose,opt,opt,-,-,mFaceNose*,-
Chin,Chin / LChin / RChin,-,-,-,opt,-,Chin,opt,opt,-,-,mFaceChin,-
Left / Right Ear,LEar / REar,-,-,-,-,-,-,-,-,-,-,mFaceEar*,-
LeftCheek,LCheek,-,-,-,opt,-,LCheek,opt,opt,-,-,mFaceCheek(Upper/Lower)Left,-
RightCheek,RCheek,-,-,-,opt,-,RCheek,opt,opt,-,-,mFaceCheek(Upper/Lower)Right,-
Mouth,Mouth,-,-,-,opt,-,Mouth,opt,opt,-,-,-,-
UpperLip,UpLip / LUpLip / RUpLip,-,-,-,opt,-,UpLip,opt,opt,-,-,mFaceLipUpper*,-
LowerLip,LoLip / LLoLip / RLoLip,-,-,-,opt,-,LoLip,opt,opt,-,-,mFaceLipLower*,-
LeftLipCorner,LLipCorner,-,-,-,opt,-,LLipCorner,opt,opt,-,-,mFaceLipCornerLeft,-
RightLipCorner,RLipCorner,-,-,-,opt,-,RLipCorner,opt,opt,-,-,mFaceLipCornerRight,-
Brow,LBrow / Brow,-,-,-,opt,-,LBrow / RBrow,opt,opt,-,-,mFaceEyebrow*,-
LeftShoulder,LShldr,LeftShoulder,lclavicle,leftShoulder,clavicle_l,LShldr,LShldr,LeftShoulder,Clavicle_L,LeftShoulder,LeftShoulder,mCollarLeft/L_CLAVICLE,LeftUpperArm,l_clavicle
LeftUpperArm,LArm,LeftArm,lhumerus,leftUpperArm,humerus_l,LArm,LArm,LeftArm,UpperArm_L,LeftUpperArm,LeftUpperArm,mShoulderLeft/L_UPPER_ARM,-,l_uparm
LeftLowerArm,LElbow,LeftForeArm,lradius,leftLowerArm,radius_l,LForeArm,LForeArm,LeftForeArm,LowerArm_L,LeftLowerArm,LeftLowerArm,mElbowLeft/L_LOWER_ARM,LeftLowerArm,l_lowarm
LeftHand,LHand,LeftHand,lwrist,leftHand,hand_l,LHand,LHand,LeftHand,Hand_L,LeftHand,LeftHand,mWristLeft/L_HAND,LeftHand,l_wrist
LeftThumbMetacarpal,LThumb,-,lthumb,leftThumbMetacarpal,opt,-,LThumb,LThumb,opt,LeftThumbProximal,LeftThumbMetacarpal,mHandThumb1Left,l_thumb0
LeftThumbProximal,LThumbMid,-,-,leftThumbProximal,opt,-,LThumbMid,LThumbMid,opt,LeftThumbIntermediate,LeftThumbProximal,mHandThumb2Left,l_thumb1
LeftThumbDistal,LThumbTip,-,-,leftThumbDistal,opt,-,LThumbTip,LThumbTip,opt,LeftThumbDistal,LeftThumbDistal,mHandThumb3Left,l_thumb2
LeftThumbTip,LThumbEnd,-,-,-,opt,-,LThumbEnd,LThumbEnd,opt,-,-,-,l_thumb_null
LeftIndexProximal,LIndex,-,lindex,leftIndexProximal,opt,-,LIndex,LIndex,opt,LeftIndexProximal,LeftIndexProximal,mHandIndex1Left,l_index1
LeftIndexIntermediate,LIndexMid,-,-,leftIndexIntermediate,opt,-,LIndexMid,LIndexMid,opt,LeftIndexIntermediate,LeftIndexIntermediate,mHandIndex2Left,l_index2
LeftIndexDistal,LIndexTip,-,-,leftIndexDistal,opt,-,LIndexTip,LIndexTip,opt,LeftIndexDistal,LeftIndexDistal,mHandIndex3Left,l_index3
LeftIndexTip,LIndexEnd,-,-,-,opt,-,LIndexEnd,LIndexEnd,opt,-,-,-,l_index_null
LeftMiddleProximal,LMiddle,-,-,leftMiddleProximal,opt,-,LMiddle,LMiddle,opt,LeftMiddleProximal,LeftMiddleProximal,mHandMiddle1Left,l_middle1
LeftMiddleIntermediate,LMiddleMid,-,lmiddle,leftMiddleIntermediate,opt,-,LMiddleMid,LMiddleMid,opt,LeftMiddleIntermediate,LeftMiddleIntermediate,mHandMiddle2Left,l_middle2
LeftMiddleDistal,LMiddleTip,-,-,leftMiddleDistal,opt,-,LMiddleTip,LMiddleTip,opt,LeftMiddleDistal,LeftMiddleDistal,mHandMiddle3Left,l_middle3
LeftMiddleTip,LMiddleEnd,-,-,-,opt,-,LMiddleEnd,LMiddleEnd,opt,-,-,-,l_middle_null
LeftRingMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,-
LeftRingProximal,LRing,-,lring,leftRingProximal,opt,-,LRing,LRing,opt,LeftRingProximal,LeftRingProximal,mHandRing1Left,l_ring1
LeftRingIntermediate,LRingMid,-,-,leftRingIntermediate,opt,-,LRingMid,LRingMid,opt,LeftRingIntermediate,LeftRingIntermediate,mHandRing2Left,l_ring2
LeftRingDistal,LRingTip,-,-,leftRingDistal,opt,-,LRingTip,LRingTip,opt,LeftRingDistal,LeftRingDistal,mHandRing3Left,l_ring3
LeftRingTip,LRingEnd,-,-,-,opt,-,LRingEnd,LRingEnd,opt,-,-,-,l_ring_null
LeftPinkyMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,l_pinky0
LeftPinkyProximal,LPinky,-,lpinky,leftLittleProximal,opt,-,LPinky,LPinky,opt,LeftLittleProximal,LeftLittleProximal,mHandPinky1Left,l_pinky1
LeftPinkyIntermediate,LPinkyMid,-,-,leftLittleIntermediate,opt,-,LPinkyMid,LPinkyMid,opt,LeftLittleIntermediate,LeftLittleIntermediate,mHandPinky2Left,l_pinky2
LeftPinkyDistal,LPinkyTip,-,-,leftLittleDistal,opt,-,LPinkyTip,LPinkyTip,opt,LeftLittleDistal,LeftLittleDistal,mHandPinky3Left,l_pinky3
LeftPinkyTip,LPinkyEnd,-,-,-,opt,-,LPinkyEnd,LPinkyEnd,opt,-,-,-,l_pinky_null
RightShoulder,RShldr,RightShoulder,rclavicle,rightShoulder,clavicle_r,RShldr,RShldr,RightShoulder,Clavicle_R,RightShoulder,RightShoulder,mCollarRight/R_CLAVICLE,RightUpperArm,r_clavicle
RightUpperArm,RArm,RightArm,rhumerus,rightUpperArm,humerus_r,RArm,RArm,RightArm,UpperArm_R,RightUpperArm,RightUpperArm,mShoulderRight/R_UPPER_ARM,-,r_uparm
RightLowerArm,RElbow,RightForeArm,rradius,rightLowerArm,radius_r,RForeArm,RForeArm,RightForeArm,LowerArm_R,RightLowerArm,RightLowerArm,mElbowRight/R_LOWER_ARM,RightLowerArm,r_lowarm
RightHand,RHand,RightHand,rwrist,rightHand,hand_r,RHand,RHand,RightHand,Hand_R,RightHand,RightHand,mWristRight/R_HAND,RightHand,r_wrist
RightThumbMetacarpal,RThumb,-,rthumb,rightThumbMetacarpal,opt,-,RThumb,RThumb,opt,RightThumbProximal,RightThumbMetacarpal,mHandThumb1Right,r_thumb0
RightThumbProximal,RThumbMid,-,-,rightThumbProximal,opt,-,RThumbMid,RThumbMid,opt,RightThumbIntermediate,RightThumbProximal,mHandThumb2Right,r_thumb1
RightThumbDistal,RThumTip,-,-,rightThumbDistal,opt,-,RThumbTip,RThumbTip,opt,RightThumbDistal,RightThumbDistal,mHandThumb3Right,r_thumb2
RightThumbTip,RThumEnd,-,-,-,opt,-,RThumbEnd,RThumbEnd,opt,-,-,-,r_thumb_null
RightIndexMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,-
RightIndexProximal,RIndex,-,rindex,rightIndexProximal,opt,-,RIndex,RIndex,opt,RightIndexProximal,RightIndexProximal,mHandIndex1Right,r_index1
RightIndexIntermediate,RIndexMid,-,-,rightIndexIntermediate,opt,-,RIndexMid,RIndexMid,opt,RightIndexIntermediate,RightIndexIntermediate,mHandIndex2Right,r_index2
RightIndexDistal,RIndexTip,-,-,rightIndexDistal,opt,-,RIndexTip,RIndexTip,opt,RightIndexDistal,RightIndexDistal,mHandIndex3Right,r_index3
RightIndexTip,RIndexEnd,-,-,-,opt,-,RIndexEnd,RIndexEnd,opt,-,-,-,r_index_null
RightMiddleMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,-
RightMiddleProximal,RMiddle,-,rmiddle,rightMiddleProximal,opt,-,RMiddle,RMiddle,opt,RightMiddleProximal,RightMiddleProximal,mHandMiddle1Right,r_middle1
RightMiddleIntermediate,RMiddleMid,-,-,rightMiddleIntermediate,opt,-,RMiddleMid,RMiddleMid,opt,RightMiddleIntermediate,RightMiddleIntermediate,mHandMiddle2Right,r_middle2
RightMiddleDistal,RMiddleTip,-,-,rightMiddleDistal,opt,-,RMiddleTip,RMiddleTip,opt,RightMiddleDistal,RightMiddleDistal,mHandMiddle3Right,r_middle3
RightMiddleTip,RMiddleEnd,-,-,-,opt,-,RMiddleEnd,RMiddleEnd,opt,-,-,-,r_middle_null
RightRingMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,-
RightRingProximal,RRing,-,rring,rightRingProximal,opt,-,RRing,RRing,opt,RightRingProximal,RightRingProximal,mHandRing1Right,r_ring1
RightRingIntermediate,RRingMid,-,-,rightRingIntermediate,opt,-,RRingMid,RRingMid,opt,RightRingIntermediate,RightRingIntermediate,mHandRing2Right,r_ring2
RightRingDistal,RRingTip,-,-,rightRingDistal,opt,-,RRingTip,RRingTip,opt,RightRingDistal,RightRingDistal,mHandRing3Right,r_ring3
RightRingTip,RRingEnd,-,-,-,opt,-,RRingEnd,RRingEnd,opt,-,-,-,r_ring_null
RightPinkyMetacarpal,-,-,-,-,-,-,-,-,-,-,-,-,r_pinky0
RightPinkyProximal,RPinky,-,rpinky,rightLittleProximal,opt,-,RPinky,RPinky,opt,RightLittleProximal,RightLittleProximal,mHandPinky1Right,r_pinky1
RightPinkyIntermediate,RPinkyMid,-,-,rightLittleIntermediate,opt,-,RPinkyMid,RPinkyMid,opt,RightLittleIntermediate,RightLittleIntermediate,mHandPinky2Right,r_pinky2
RightPinkyDistal,RPinkyTip,-,-,rightLittleDistal,opt,-,RPinkyTip,RPinkyTip,opt,RightLittleDistal,RightLittleDistal,mHandPinky3Right,r_pinky3
RightPinkyTip,RPinkyEnd,-,-,-,opt,-,RPinkyEnd,RPinkyEnd,opt,-,-,-,r_pinky_null
LeftUpperLeg,LLeg,LeftUpLeg,lfemur,leftUpperLeg,femur_l,LThigh,LThigh,LeftUpLeg,Thigh_L,LeftUpperLeg,LeftUpperLeg,mHipLeft/L_UPPER_LEG,LeftUpperLeg,l_upleg
LeftLowerLeg,LKnee,LeftLeg,ltibia,leftLowerLeg,tibia_l,LLeg,LLeg,LeftLeg,Calf_L,LeftLowerLeg,LeftLowerLeg,mKneeLeft/L_LOWER_LEG,LeftLowerLeg,l_lowleg
LeftFoot,LFoot,LeftFoot,lfoot,leftFoot,foot_l,LFoot,LFoot,LeftFoot,Foot_L,LeftFoot,LeftFoot,mAnkleLeft/L_FOOT,LeftFoot,l_foot
LeftFoot1,-,-,-,-,-,-,-,-,-,-,-,mFootLeft,l_talocrural
LeftToes,LToes,EndSite,ltoes,leftToes,opt,-,LeftToes,LeftToeBase,Toe_L (opt),LeftToes (opt),LeftToes,mToeLeft,l_ball
LeftToesTip,LTip,-,-,-,opt,-,LTip,-,LeftTip (opt),-,-,-,-
RightUpperLeg,RLeg,RightUpLeg,rfemur,rightUpperLeg,femur_r,RThigh,RThigh,RightUpLeg,Thigh_R,RightUpperLeg,RightUpperLeg,mHipRight/R_UPPER_LEG,RightUpperLeg,r_upleg
RightLowerLeg,RKnee,RightLeg,rtibia,rightLowerLeg,tibia_r,RLeg,RLeg,RightLeg,Calf_R,RightLowerLeg,RightLowerLeg,mKneeRight/R_LOWER_LEG,RightLowerLeg,r_lowleg
RightFoot,RFoot,RightFoot,rfoot,rightFoot,foot_r,RFoot,RFoot,RightFoot,Foot_R,RightFoot,RightFoot,mAnkleRight/R_FOOT,RightFoot,r_foot
RightFoot1,-,-,-,-,-,-,-,-,-,-,-,mFootRight,r_talocrural
RightToes,RToes,EndSite,rtoes,rightToes,opt,-,-,RightToeBase,Toe_R (opt),RightToes (opt),RightToes,mToeRight,r_ball
RightToesTip,RTip,-,-,-,opt,-,RTip,-,RightTip (opt),-,-,-,-