RoboRig: Tell a Humanoid What to Do

A model. An instruction. A moving humanoid.

Making a humanoid move is still much harder than it ought to be. RoboRig makes the first step simple: upload 3d model of a humanoid (GLB), say what it should do, draw where it should go, and receive a rigged, animated asset you can inspect, replay, and reuse.

The problem

A static 3D humanoid is only a shell. Before a team can test whether it should move cautiously, hurry, signal success, approach an interaction point, or follow a route, someone has to make that intent visible in motion.

Normally, every change sends the model back through a specialist workflow. That makes early exploration slow and expensive. More importantly, it means good ideas often never get tested.

What RoboRig does

  1. Start with a humanoid GLB. RoboRig creates a rig and lets you inspect it in the browser.
  2. State the intent. Type it in plain English or speak it through live Voice Mode.
  3. Draw the direction. A route drawn in the 3D viewport becomes root-motion waypoints.
  4. Generate in the background. The GPU pipeline produces full-body movement while the workspace remains usable.
  5. Receive a real asset. RoboRig validates and returns an animated GLB, not a video or a stock walk cycle.

The prompt says how; the route says where. Keep the route and change the words. The same destination can become a stealthy walk, a limp, a sprint, or a celebration. RoboRig supports far more than walking and running: locomotion, gestures, expressive actions, interactions, and sequences such as sitting, leaning, peeking, pick-and-put actions, and victory dances.

Why it matters

RoboRig makes the first draft of humanoid movement easier to create, compare, and refine before scarce animation or simulation time is spent. It is built for robotics simulation, motion prototyping, previsualization, and character-animation workflows. It does not control a physical robot. It helps teams test embodied intent earlier.

Built with Codex and GPT

I used Codex to take RoboRig from an idea to a deployed product. It helped me design, develop, test, secure, and deploy the interactive 3D workspace, GPU job queue, rigging and motion pipeline, validation system, Docker image, Northflank GPU hosting, live job feedback, and server-side credential protection.

GPT-5.6-Sol is part of the real recovery path. If a rigging or animation job fails, it chooses one bounded action: base rigging, retrying a transient failure, or manual review. There is a deterministic fallback if the model cannot respond. It does not generate the motion; it makes the system more dependable.

GPT voice turns spoken intent into live text in the motion prompt and provides feminine voice responses. GPT Image created the original robot concept, which I converted into the GLB used in the project.

RoboRig turns a robot concept into a moving digital character: image → model → skeleton → instruction → route → motion.

How Codex and GPT-5.6 built RoboRig

Codex accelerated the product from a blank canvas to a deployed GPU application. The key product decision was to keep one simple journey together: static GLB → rig → instruction and route → validated animated GLB. Codex helped turn that journey into a working experience rather than a collection of disconnected tools.

Key decisions Codex helped implement and verify:

  • Product focus: make the 3D viewport, AI Rig, AI Animate, voice input, drawn route, and export feel like one continuous workflow instead of exposing a traditional animation timeline.
  • Reliable GPU work: keep motion generation deterministic in isolated GPU workers, run jobs in the background, validate outputs before returning them, and retain cache/history so iteration does not repeat expensive work.
  • Production readiness: package the complete stack in Docker, deploy it to a single Northflank GPU service with persistent model storage, add health checks, protect the application with server-side Basic Auth, and keep all API keys and model credentials server-side.

GPT-5.6-Sol is integrated in the recovery path, not used as a decorative label. After a failed job, it chooses exactly one bounded action: use the base rig path, retry a transient animation failure, or stop for manual review. A deterministic fallback applies if the model cannot respond. This makes the failure path safer and more useful without misrepresenting GPT-5.6 as the motion generator.

Built With

Share this project:

Updates