Fountain Coach Gitowner-controlled · read only

laban-rig.git · README.md

laban-rig.git / README.md

revision fc813fbf6ee5e1554e429fb8bf91ffb33f310308 · complete file

# Canonical Humanoid Rig (ARKit + Laban) – Package

**Version:** 1.0.0  
**Date:** 2025-12-08

This package defines a **canonical humanoid rig description** that

- is directly **compatible with Apple's ARKit/iPhone mocap skeleton** (`ARSkeletonDefinition.defaultBody3D`),
- abstracts that skeleton into a **notation-agnostic JSON schema**,
- provides a **Laban-friendly grouping** of joints into body parts (TRUNK, ARM_LEFT, etc.),
- is designed to be easily mapped into common 3D / animation formats (USD/USDC/USDZ, FBX, glTF, BVH),
- is written to be **read and followed by an LLM** in other environments.

The package contains three files:

1. **README.md** – this document (high-level explanation and usage hints).
2. **canonical_rig.json** – a JSON file containing:
   - a validation **schema** for the canonical skeleton description, and
   - an **example skeleton instance** using a small, analysis-oriented subset of ARKit joints.
3. **EXTENSIBILITY.md** – guidelines on how to extend this rig description for:
   - more joints (hands, fingers, face),  
   - other source skeletons (e.g. Mixamo, Unreal Mannequin, SMPL, BVH),  
   - other analysis systems (e.g. Labanotation, Laban Movement Analysis, Effort categories).

---

## Concept in One Paragraph

The canonical rig is defined as an **abstract skeleton** composed of joints with the following attributes:

- `id` – a stable, human-readable canonical identifier (e.g. `"pelvis"`, `"spine_upper"`),
- `name` – the native name in the *source* skeleton (e.g. ARKit's `"hips_joint"`),
- `parentId` – the canonical parent joint,
- `side` – `"CENTER"`, `"LEFT"`, or `"RIGHT"`,
- `role` – a semantic role (e.g. `PELVIS`, `SPINE_UPPER`, `KNEE`, `WRIST`),
- `labanPart` – a coarse Laban body-region (e.g. `TRUNK`, `ARM_LEFT`, `FOOT_RIGHT`),
- `restTransform` – a 4×4 local matrix in the bind pose (or `null` if handled elsewhere).

LLMs and tools can use this description to **translate between**:

- **iPhone mocap data** (ARKit joint transforms),
- **procedural or symbolic movement descriptions** (e.g. “right arm forward-high for 0.5s”),
- **Laban-style movement notation**, which works on body segments (arm, leg, trunk, head),
- **engine-specific rigs** (Unity, Unreal, Blender, etc.), by mapping the canonical `id` to engine bones.

---

## How to Use this Package with an LLM

### 1. Provide the context

When you want to instruct an LLM (in another environment) to understand or use this rig:

1. Upload / paste **`canonical_rig.json`** to that environment, or copy its contents into a prompt.
2. Optionally upload **`EXTENSIBILITY.md`** if you want the LLM to customize or expand the rig.

You can say something like:

> “Here is a JSON file describing our canonical humanoid rig based on ARKit and Laban.  
> Please read it and then follow its schema when producing any skeleton descriptions,  
> rig mappings, or procedural movement specifications.”

### 2. Mapping ARKit data into the canonical rig

Given an `ARBodyAnchor` from Apple’s ARKit:

- `jointNames[i]` → should match the `name` field in the example skeleton.
- `jointModelTransforms[i]` → the transform for that joint in the character’s model space.

The LLM or tool should:

1. Build a lookup `name → canonical id` from the `joints` array.
2. For each ARKit joint:
   - Find the matching `joints[k]` record.
   - Attach the transform to that canonical joint id in a “pose frame” structure of your choice.

This yields a rig-agnostic, Laban-aware representation of the pose.

### 3. Mapping from the canonical rig into engines or files

You can embed the canonical skeleton in:

- **USD/USDC/USDZ**: map each joint `id` or `name` to a skeleton joint name in `UsdSkel`, adding `role` and `labanPart` as custom metadata.
- **FBX**: use the same joint names in the node hierarchy; attach extras for `role` and `labanPart`.
- **glTF**: store joints as nodes; use `extras` to store the canonical metadata.
- **BVH**: define a reduced hierarchy and maintain a mapping table `bvhName → canonical id` for analysis.

The key principle: **do not lose the canonical ids or semantic tags**. They are what make Laban-style reasoning portable.

---

## Relationship to Laban Notation

- Laban works primarily with **body segments** (e.g. “right arm”, “left leg”, “trunk”).  
- The canonical rig groups individual joints into **LabanPart** categories:
  - `TRUNK`, `HEAD_NECK`, `ARM_LEFT`, `ARM_RIGHT`, `LEG_LEFT`, `LEG_RIGHT`, `FOOT_LEFT`, `FOOT_RIGHT`, etc.
- For movement analysis, you typically use segments such as:
  - `pelvis → neck_top` for the trunk,
  - `shoulder_right → wrist_right` for the right arm,
  - `hip_left → ankle_left` for the left leg, etc.

These segments can then be classified into **Laban directions and levels** (forward/backward, left/right, high/middle/low) and movement durations, which are notated symbolically in Labanotation.

The canonical rig does **not** encode Laban symbols directly, but it **provides the structural information** needed to compute or realize them.

---

## File Overview (Quick Reference)

- **`canonical_rig.json`**
  - `skeletonSchema` – JSON Schema for validating canonical skeleton descriptions.
  - `exampleSkeleton` – a minimal, analysis-oriented skeleton instance with ~20 joints.

- **`EXTENSIBILITY.md`**
  - How to add more joints (fingers, face).
  - How to adapt the canonical schema to other skeleton sources.
  - How to keep Laban and ARKit compatibility when extending.

This package is intentionally minimal and text-based so it can be embedded in prompts, version-controlled, and shared as a foundation for further research or tooling.