Building a better Animation Search: How Mocap ATLAS Categorizes Human Motion

Finding the right mocap animation should be simple. In practice, it rarely is.

If you are building a game, a previs sequence, a motion-matching system, an animation graph or a character controller, you are almost never looking for "an animation." You are looking for something specific: a run turn, a walk stop, a crouch-walk cycle, a breathing idle, a 45-degree direction change, a loopable idle, a MetaHuman-ready FBX, a Unity-compatible clip, or raw C3D marker data for your own solve.

That is why we are rebuilding how motion-capture data is categorized on Mocap ATLAS. Human motion is nuanced, and a category like "walk" or "idle" stops being useful once a library holds hundreds of individual files across different formats, rigs and production workflows. Every person moves differently, so how do we describe all those variations without resorting to Walk A, Walk B, Walk C?

This article explains the taxonomy we landed on, why each field exists, and how it changes the way you search for animation data.

Key takeaways

• Broad categories like "run" or "idle" hide the differences that actually matter in production.
• Mocap ATLAS classifies every clip with structured fields: Action, Gait, Direction, Turn, Pattern, Modifier, Intensity, Style, Use Case, Start and End State.
• Direction, turn and pattern are kept separate, so a sideways run is still a run, not a new gait.
• Product titles, package names and file names follow the same structure, so downloads sort cleanly inside your project.
• Simple filters stay visible by default; technical filters live under advanced filtering.

Why filtering animation data is harder than it looks

Most online animation stores use broad categories: idle, walk, run, combat, sport, dance, daily life, fantasy. That works well for browsing packs. It breaks down when every animation is sold and documented as an individual file.

A single "run" animation can mean any of the following:

• a straight forward run
• a run turn to the right or left
• a run pattern recorded for motion matching
• a run start or stop
• a run with full stops before each turn
• a run with continuous direction changes

These are not interchangeable. Picking the wrong one means extra retargeting work, a controller that behaves oddly, or a clip that simply does not fit the gameplay system you are building.

Idles are even worse. "Idle" usually means neutral standing, but the label covers a range of variations like heavy breathing, exhausted body motion, look-around behavior, fidgeting, a combat-ready stance, a crouched stealth idle and an injured idle. A good animation store has to surface those differences without overwhelming the person browsing.

The problem with one-size-fits-all categories

When we reviewed how animation marketplaces organize motion data, we found that most rely on broad groups, plain keyword search, or pack-level organization. That is understandable: it keeps the interface simple, and most marketplaces support many asset types beyond animation.

Mocap ATLAS only does motion-capture animation data. That focus lets us treat every clip as structured motion data rather than a thumbnail with a title. As far as we can tell, it makes Mocap ATLAS one of the very few mocap animation stores built around this level of file-level filtering fidelity, where you can search not just by category, but by how the motion behaves.

Who we are building this for

Beginners

A first-time buyer usually wants an idle animation, a walk cycle, a run animation, a Unity-ready FBX, a MetaHuman-compatible file, or a free mocap animation to test their pipeline. For them, the interface has to stay clear. Nobody should need to learn a vocabulary before finding something useful.

Game developers and technical animators

A technical buyer searches very differently:

• run turn 45 degrees right
• walk-jog-run speed transitions
• crouch-walking animations
• strafed or angled movement with turns
• motion-matching source data
• loopable, game-ready animations
• UE5 Manny retargeted FBX
• raw C3D marker data with reference video

Broad categories cannot answer any of those queries. The store needs deeper metadata.

Researchers and mocap professionals

A data-focused buyer cares about raw source takes, C3D marker files, BVH exports, FBX skeleton data, reference video, finger capture, capture system, duration, frame rate, source project, actor identity and the original take identity. Those details need to be available without turning the shopping experience into a database form.

The Mocap ATLAS motion taxonomy

Each field has exactly one job. That is deliberate: it prevents a label like "Idle" from appearing as a category, a gait and a pose at the same time.

We deliberately dropped a separate public "Posture" field. For the current catalog it would mostly repeat what Gait, Start State and End State already say. Crouch-walk content is findable through Gait; falls and get-ups through Action and the state fields. Keeping the model lean avoids the duplicated metadata that makes so many animation libraries painful to maintain.

Production and delivery metadata

Production details are handled separately. Some are public, others live in the product specification or stay internal:

• Looping: a simple Yes or No.
• Loop Quality: whether the clip already loops seamlessly, or contains raw loopable poses you can cut and edit yourself.
• Duration: exact seconds, plus a human-friendly duration range.
• Processing: raw source, retargeted, cleaned or game-ready animations.
• Format: FBX, BVH, C3D, reference video, and other delivery files.
• Available Rigs: the retargeted skeleton rigs and formats offered for that clip.
• Source Project: the capture project or shoot day the clip belongs to.
• Reference Video, Finger Data, Capture System, Capture FPS, Delivery FPS, Data Quality, Gender, Role, Props: the production details technical buyers use to evaluate an asset.

Direction, Turn and Pattern are three different things

The single most useful refinement was splitting these apart:

Take a sideways running strafe. It should not become its own gait. It is still a run: the direction is sideways, and the turn value tells you whether facing changes.

• Gait: Run
• Direction: 90R
• Turn: No Turn

That is far cleaner than inventing a gait called "Run Strafe", and it means one filter combination finds every strafe in the catalog, at any speed.

Three worked examples

1. Run Turn 135R

The product title stays short. Underneath, the clip is described precisely:

• Action: Turn
• Gait: Run
• Direction: Forward
• Turn: Turn 135R
• Pattern: None
• Start State: Running  |  End State: Running
• Use Case: Locomotion Controller, Motion Matching, Animation Graph
• Looping: No

Someone scanning the grid sees a short, structured name. Someone opening the product page gets the production detail.

2. Run Card Stop-Turns

Some source clips are more complex than a single turn. In a dance-card pattern, the performer runs, comes to a full stop, turns, then continues in a new direction.

• Action: Locomotion
• Gait: Run
• Direction: Multi-Directional
• Turn: Turns Left and Right
• Pattern: Dance Card
• Modifier: Stop-Turns
• Style: Neutral or Athletic, depending on the source motion
• Use Case: Motion Matching, Locomotion Controller

The distinction matters. "Run Card Stop-Turns" tells a technical buyer this is not a generic run clip: it contains structured behavior that is directly useful for motion matching, stop/start logic and direction-change sampling.

3. Idle Breathing Heavy

A typical marketplace would call this "Heavy Breathing Idle." We invert it on purpose. Buyers scan libraries by function, so leading with "Idle" groups similar files visually and keeps downloads tidy inside a game project.

• Action: Idle
• Direction: Stationary
• Turn: No Turn
• Pattern: None
• Modifier: Breathing
• Intensity: Heavy
• Style: Neutral, Tired or Exhausted, depending on the performance
• Start State: Standing Idle  |  End State: Standing Idle
• Use Case: Game-Ready Idle, NPC Variation
• Looping: Yes

The title, package and file name follow the same logic:

• Product title: Idle Breathing Heavy
• Package name: MML25_Idle_Breathing_Heavy.zip
• Developer file name: MML25_Idle_Breathing_Heavy

One naming convention across the store, the download and your local project folder.

Why structured file names help developers

Nobody working in Unreal Engine, Unity, Blender, MotionBuilder or Maya wants file names that read like marketing copy. They want files that sort logically:

• MML25_Idle_Breathing_Heavy
• MML25_Idle_Exhausted
• MML25_Idle_LookAround
• MML25_Run_Card_StopTurns
• MML25_Run_Turn_45R
• MML25_WalkJogRun_SpeedChange

The first word says what it is. Everything after it refines the behavior. The same logic makes the product grid easier to scan than a list of loosely written titles that all end in "mocap animation."

Motion matching needs richer metadata

Motion matching and learned locomotion systems feed on dense, structured samples. One clean walk cycle is useful; a motion-matching database needs far more: turns, starts, stops, speed changes, direction changes, multi-directional samples and repeated patterns.

That is why Snake, Circle, Square, Diamond, Star and Dance Card get their own metadata field. These are not decorative descriptions. They tell you how the performer moved through space, and therefore how useful the clip will be when you build a locomotion system.

The Motion Matching Library 2025 is built around exactly this idea, with raw source takes, reference videos, C3D marker data, BVH, FBX and retargeted variants for common production targets.

Simple by default, deep on demand

More metadata does not mean more filters on screen. We layer the filtering experience instead.

Default filters: Action, Gait, Use Case, Format, Available Rigs, Processing, Looping, Duration Range.

Advanced filters: Direction, Turn, Pattern, Modifier, Intensity, Style, Start State, End State, Reference Video, Finger Data, Capture System, Gender, Role, Prop, Source Project.

Beginners get an approachable entry point; professionals get the precision they expect from a serious motion-capture library. We also hide filters that are empty, redundant or not yet useful for the current catalog.

Raw source, retargeted and game-ready

• Raw Source Takes preserve the full studio recording and source data for advanced workflows.
• Retargeted Takes are mapped to common skeletons and rigs.
• Game-Ready Clips are final edited clips for direct integration into a game or rendering engine.

Not every buyer needs the same thing. A researcher may want raw C3D marker data. A technical animator may want BVH or FBX. A game developer may want UE5 Manny, UE5 MetaHuman, Unity 6, Mixamo, iClone or CC3 variants. Format and Available Rigs always reflect what is actually purchasable for that product, not a hand-written promise that drifts away from the variant data.

What we are deliberately not modeling yet

Half of a useful taxonomy is deciding what not to track. There is no separate public posture filter, because Action, Gait, Start State and End State already carry that information. Performer metadata stays simple: Gender and Role, rather than four overlapping fields for performer type, character type, character role and class.

Hand behavior is covered through Modifier and Prop where it matters. If future weapon, prop or interaction libraries need more precision, we can add deeper hand-use metadata then. For now the priority is a catalog that is precise without being overcomplicated.

Who builds Mocap ATLAS

Mocap ATLAS is produced by Quantum Stage, a motion-capture studio in Switzerland. Every animation is performed by real human actors and captured with a professional optical motion-capture workflow. The goal is not to sell generic motion clips. It is to make high-quality human motion data accessible, searchable and usable. You can read more about Mocap ATLAS.

Frequently asked questions

What is the difference between Direction and Turn?

Direction is where the body travels relative to its facing direction. Turn is whether the facing direction itself changes. A strafing run has a sideways Direction and No Turn; a run turn travels forward but changes facing by 45, 90 or 180 degrees.

What file formats do Mocap ATLAS animations come in?

Depending on the product: FBX, BVH, C3D marker data and reference video. The Format field on each product page reflects what is actually included. Most buyers use FBX, retargeted to their own skeleton rig.

Which rigs and engines are supported?

Retargeted variants are offered for common production targets including UE5 Manny, UE5 MetaHuman, Unity 6, Mixamo, iClone and CC3. Available Rigs is generated from the purchasable variants, so it always matches what you receive.

What is a dance card in motion capture?

A dance card is a structured recording path where a performer moves through a predefined route covering every turn in 45-degree increments, both left and right. It produces dense, varied samples that are valuable for motion matching and locomotion systems.

Are there free mocap animations to test with?

Yes. You can download free mocap animations to test retargeting and your import pipeline before buying.

A better store for motion data

The long-term goal is simple: make it faster to find the right motion. Someone after a plain idle should find one in seconds. A professional after a 135-degree run turn to the left should be able to narrow the catalog to exactly those clips. A motion-matching developer should be able to find pattern-based recordings, and a researcher should be able to identify raw source data and reference material.

This is an ongoing refinement. Human motion is complex and no taxonomy will ever be perfect. But by treating animation as structured motion data rather than generic media, Mocap ATLAS becomes a genuinely better place to browse, compare and buy motion-capture assets.

Explore the current library:

• Motion Matching Library 2025
• Free Mocap Animations
• About Mocap ATLAS
• FAQ