Skip to main content

Motion data format

Understanding the motion capture data format is crucial for integrating Move API output into your applications. This guide explains the various output formats and the structure of motion data returned by the API.

Motion capture output formats​

The Move API supports multiple output formats for different use cases and applications:

FBX format​

FBX is a proprietary format widely used in 3D animation:

  • Applications: Maya, Blender, Unity, Unreal Engine
  • Content: Skeletal animation with mesh data
  • Advantages: Industry standard, rich metadata support
  • Use cases: Game development, animation pipelines, film production

GLB format​

GLB is the binary format for glTF:

  • Applications: Web applications, mobile apps, AR/VR
  • Content: 3D models with animations optimized for real-time rendering
  • Advantages: Compact, web-optimized, widely supported by modern browsers
  • Use cases: Web-based applications, mobile experiences, AR/VR content

USD formats​

USD is an open-source format for 3D scene data:

  • USDC: Binary USD format for efficient storage and transmission
  • USDZ: Compressed USD format optimized for iOS and AR applications
  • Applications: Maya, Blender, Houdini, Omniverse, custom pipelines
  • Content: Skeletal animation with scene composition capabilities
  • Advantages: Open standard, highly composable, efficient for complex scenes
  • Use cases: Film pipelines, AR experiences, collaborative workflows

BVH format​

BVH is a text-based motion capture format:

  • Applications: Motion analysis, research, academic software
  • Content: Hierarchical skeletal data with rotation channels
  • Advantages: Human-readable, compact, widely supported in research
  • Use cases: Biomechanics analysis, motion research, academic studies

C3D format​

C3D is a standard format for motion capture:

  • Applications: Biomechanics, sports analysis, clinical research
  • Content: 3D coordinate data with analog data support
  • Advantages: Industry standard for motion analysis, supports force plate data
  • Use cases: Gait analysis, sports performance, clinical assessments

Blend format​

Blend is the native format for Blender:

  • Applications: Blender 3D software
  • Content: Complete scene data with animations and materials
  • Advantages: Native Blender format, preserves all scene data
  • Use cases: Blender-based animation workflows, open-source pipelines

Video outputs​

  • Render Video: Preview video showing the motion capture visualization
  • Render Overlay Video: Preview video with motion capture data overlaid on the original video (single camera setups only)

Additional outputs​

  • Sync Data: Timing information about video offsets (.pkl format)
  • Motion Data: Raw motion capture data in JSON format (motion_data.json)

Motion Data structure​

The Move API exports detailed motion capture data in JSON format through the motion_data.json file. This section describes the structure and content of this data.

File format overview​

The motion data JSON contains frame-by-frame skeletal animation data with the following top-level structure:

{
  "mocap_data": [
    {
      "frame": 0,
      "timestamp": 0.00000,
      "joint_data": {
        // Joint data for all skeleton joints
      }
    }
  ]
}

Frame data structure​

Each frame contains:

  • frame: Frame number (integer, starting from 0)
  • timestamp: Time in seconds (float)
  • joint_data: Object containing data for all skeleton joints

Skeleton structure​

The Move API uses a biomechanically accurate skeleton with a hierarchical joint structure. The skeleton follows anatomical relationships where child joints are connected to their parent joints.

Hierarchical joint structure​

Root (Pelvis)
├── Left_hip
│   └── Left_knee
│       └── Left_ankle
│           └── Left_toe
├── Right_hip
│   └── Right_knee
│       └── Right_ankle
│           └── Right_toe
└── Spine1 (Lower spine)
    └── Spine2 (Upper spine)
        ├── Left_clavicle
        │   └── Left_shoulder
        │       └── Left_elbow
        │           └── Left_wrist
        ├── Right_clavicle
        │   └── Right_shoulder
        │       └── Right_elbow
        │           └── Right_wrist
        └── Neck

Joint data format​

Each joint contains the following data:

Position​

3D world position in meters:

"position": [-3.64648, 2.11009, 0.87155]

Rotation type and values​

Different joints use different rotation representations:

  • euler_xyz: Euler angles in XYZ order (radians)
  • euler_zyx: Euler angles in ZYX order (radians)
  • euler_x: Single-axis rotation around X (radians)
  • euler_z: Single-axis rotation around Z (radians)
  • euler_yz: Two-axis rotation YZ (radians)
  • quaternion: Quaternion representation [x, y, z, w]

Example rotation data:

"type": "euler_xyz",
"rotations": [0.01824, -0.03532, 0.08069]

Local transformation matrix​

4x3 transformation matrix representing the joint's local transform (Rotation and translation relative to its parent joint):

"local_transformation": [
  [0.99877, -0.04673, 0.01629, 0.11503],
  [0.04671, 0.99891, 0.00198, 0.00000],
  [-0.01636, -0.00121, 0.99987, 0.00000]
]

Torques​

Joint torques in Newton-meters for biomechanical analysis:

"torques": [0.50355, 0.11276, 0.66792]

Reaction forces (foot joints only)​

Ground reaction forces in Newtons for ankle and toe joints:

"reaction_forces": 210.82910

Coordinate system​

The Move API uses a right-handed coordinate system with Z-up orientation:

  • X-axis: Left to right (when facing forward)
  • Y-axis: Forward (depth)
  • Z-axis: Up (vertical)

Units​

  • Distance/Position: Meters
  • Rotation: Radians
  • Time: Seconds
  • Forces: Newtons
  • Torques: Newton-meters

Data quality and accuracy​

Motion capture quality depends on several factors:

  • Model used: Higher-tier models (s2, m2) provide greater accuracy
  • Camera setup: Multi-camera configurations improve tracking quality
  • Lighting conditions: Well-lit scenes enhance joint detection
  • Occlusion: Hidden body parts may affect tracking accuracy
  • Motion complexity: Rapid or highly complex movements can impact tracking precision. Higher frame rates help capture fast motions more accurately

Working with motion data​

Loading and parsing​

The motion_data.json file can be loaded and processed in any programming language that supports JSON parsing. The data structure is designed to be both human-readable and machine-processable.

Integration considerations​

When integrating motion data into your application:

  1. Coordinate system: Ensure your application uses the same right-handed coordinate system
  2. Units: Convert units if your application uses different measurements
  3. Frame rate: Handle frame rate differences between source and target applications
  4. Joint mapping: Map our skeleton joints to your application's bone structure

Next steps​