Skip to main content
🤖AI-generated documentation curatedAI Generated
This page was drafted by an AI assistant and may contain inaccuracies.
About content generation types
🤖
AI GeneratedPage drafted entirely by AI from codebase or prompt instructions.
(e.g., docs generated from codebase analysis)
← this page
✋→🤖
AI TransformattedHuman provided raw material; AI restructured it into a different format.
(e.g., livestream → blog post, meeting notes → docs)
Human GeneratedPage written entirely by a human author.
(e.g., hand-written tutorial)
More info about content generation types ↗

Architecture Overview

FreeMoCap is a markerless motion capture system. A React/Electron desktop UI talks to a Python backend over REST and WebSocket, streaming live multi-camera video, recording synchronized footage, and processing it into 3D skeleton data.

This page gives you the system-level picture. The pages that follow zoom into each layer — frontend, API boundary, and backend — so you can drill to whatever depth you need.

System Diagram

Two communication channels between frontend and backend:

  • REST API (localhost:53117) — Commands: detect cameras, start/stop recording, run calibration, process mocap, export to Blender. HTTP request/response.
  • WebSocket (localhost:53117/websocket/connect) — Streaming data: live camera frames (binary JPEG), keypoints, logs, framerate stats, pipeline progress. Persistent connection with auto-reconnect.

There's also Electron IPC for desktop-specific operations (file system dialogs, native menus, auto-updater) via a tRPC proxy — but the core system works in a browser too.

Repository Map

freemocap/
├── freemocap-ui/ React/TypeScript frontend (Electron desktop app)
│ └── src/
│ ├── app/ Entry points (main.tsx, App.tsx, AppContent.tsx)
│ ├── layout/ Panel layout + routing (BasePanelLayout, BaseContentRouter)
│ ├── pages/ Top-level page components
│ ├── components/ Shared + domain components
│ ├── services/ Backend communication (WebSocket, REST, Electron IPC)
│ ├── store/ Redux state management (13 slices)
│ ├── styles/ CSS utility classes + design tokens
│ ├── hooks/ Custom React hooks
│ ├── i18n/ Internationalization (41 locales)
│ ├── types/ Shared TypeScript types
│ ├── utils/ Pure utility functions
│ └── constants/ URLs, external links

├── freemocap/ Python backend (FastAPI, WebSocket, processing pipelines)

├── freemocap-docs/ This documentation site (Docusaurus v3 + SkellyDocs)

└── shared/ Shared assets (charuco boards, logos, macOS packaging)

FreeMoCap builds on two sibling projects, each with its own docs site: SkellyCam (the camera backend) and SkellyTracker (the pose-estimation backend).

Communication Flow

Design Philosophy

These principles shape every decision in the codebase. They're non-negotiable.

Depth-Stackable Complexity

Everything in FreeMoCap should be approachable for a newcomer while exposing full power for experts. The UI defaults to sensible paths, but advanced controls are never hidden — just organized so you find them when you need them.

This documentation follows the same rule. Every page starts with a summary you can read in 30 seconds. Keep scrolling and you hit full implementation detail.

Fail Loudly

The default is to crash with a clear error message rather than silently degrading. This surfaces bugs immediately instead of papering over them. Valid exception handling is used at system boundaries (user input validation, external API responses, GPU OOM recovery, network reconnection) and for graceful degradation when optional features are unavailable (e.g., falling back to CPU inference when a GPU execution provider is missing).

Single Source of Truth

Every decision — backend selection, config flag, feature toggle — should have exactly one definition. No duplicated boolean flags. No config keys defined in two places that can drift out of sync. The architecture docs tell you where the canonical location is. (In practice, a few constants like the port number and WebSocket path are necessarily duplicated at the frontend/backend boundary — these are documented in both server-urls.ts and server_constants.py.)

Zero Backwards Compatibility (Aspirational)

New code targets the current architecture without shims or migration layers. However, the project retains some legacy compatibility: the RecordingStructure model supports both canonical and legacy recording layouts, and some pipeline configs offer legacy operating modes (e.g., inline per-camera skeleton detection vs the default centralized GPU inference). Legacy support is pragmatic — it keeps existing recordings usable while the system evolves.

Quick Reference

Which file owns what?

ConcernCanonical location
App entry pointfreemocap-ui/src/main.tsx
Provider hierarchy + routingfreemocap-ui/src/app/AppContent.tsx
Panel layoutfreemocap-ui/src/layout/BasePanelLayout.tsx
Route definitionsfreemocap-ui/src/layout/content/BaseContentRouter.tsx
Redux store configfreemocap-ui/src/store/store.ts
WebSocket + frame processingfreemocap-ui/src/services/server/ServerContextProvider.tsx
REST API endpointsfreemocap-ui/src/constants/server-urls.ts
CSS design tokensfreemocap-ui/src/styles/color.css
CSS utility classesfreemocap-ui/src/styles/App.css
i18n configurationfreemocap-ui/src/i18n/i18n.ts

Ports and URLs

WhatDefault
Backend HTTPhttp://localhost:53117
Backend WebSocketws://localhost:53117/websocket/connect
Production domainhttps://freemocap.org

Key dependencies (frontend)

PackagePurpose
react / react-domUI framework
@reduxjs/toolkit / react-reduxState management
react-router-domClient-side routing (HashRouter)
react-resizable-panelsDraggable panel layout
react-grid-layoutCamera grid with drag-to-reorder
three / @react-three/fiber3D skeleton viewport
d3Framerate charts
i18next / react-i18nextInternationalization
zodRuntime schema validation
electronDesktop packaging
viteBuild tool and dev server