Kinema v0.1.0

Every Blender robotics tool today — Phobos, LinkForge, urdf_importer, blender-urdf —
treats Blender as a design and export station for URDF/SDF. They optimise for producing
simulation assets. Kinema optimises for the opposite thing: open a .blend, find a clean
rig, animate it, hit render. Blender is the destination, not a stop along the way.

This is the first release.

Install

Download the one zip that matches your operating system. Each is self-contained; you do not
need the others, and you do not need to install anything else.

Platform	Asset	Size
Windows (x64)	kinema-0.1.0-windows_x64.zip	118.8 MB
Linux (x64)	kinema-0.1.0-linux_x64.zip	138.7 MB
macOS (Apple silicon)	kinema-0.1.0-macos_arm64.zip	102.0 MB

Then drag the zip into a Blender window, or use
Edit > Preferences > Get Extensions > Install from Disk. Step-by-step instructions per
platform are in the install guide.

Blender 5.2 LTS or newer is required. It embeds CPython 3.13, which is what the bundled
wheels are built for; earlier Blender versions will not load them. Nothing else needs
installing — JAX, SciPy, lxml and the rest ship inside the zip, and the solver source is
vendored. That is also why the zips are large: each carries its own platform's jaxlib.

Intel Macs are not currently built. If you need one, open an issue.

What it does

Import a robot. Pick from a catalog of 186 real robots — arms, humanoids, quadrupeds,
drones, end effectors — and Kinema downloads what it needs on first use, no git binary
required. Or point it at your own URDF, xacro or MJCF file, with package:// references
resolved from the file's own tree. Imports run on a worker thread with rig building spread
across modal ticks, so Blender stays responsive and Esc cancels.

Kinema also ships a COLLADA (.dae) reader, exposed on its own as File > Import >
COLLADA. Blender 5.0 removed the built-in COLLADA module, and a large share of ROS and
Gazebo descriptions still reference .dae meshes — without this, an otherwise valid URDF
imports as a robot with no visible geometry.

Get one armature you can actually animate. Not armatures nested inside armatures: one
rig, with one 1-DoF bone per joint and the bone's local Y aligned to the joint axis, so a
single channel is the joint value and everything else is locked. Real limits come from the
description and can be switched off when a shot needs a pose the robot cannot reach. Fixed
joints get no bone. Bones are sorted into Kinema/FK, Kinema/IK, Kinema/TCP and
Kinema/Mechanism collections so you see controls, not machinery, and link meshes are
parented rigidly rather than skinned, because robot links are rigid bodies.

Keyframe the tool. The IK target is an ordinary Blender bone — move it, key it, done —
but it is solved by PyRoki rather than Blender's built-in solver, so it honours the
robot's real joint limits and steers away from singularities.

Where that matters most is multi-turn joints. Blender's own IK clamps its per-bone limits to
±180°, while five of the UR5e's six joints travel ±360° — so the built-in solver gets half
the real range whatever you set. Spin the tool through two full turns and it snaps the wrist
about 176° in a single frame, twice, at the half-turn and the turn-and-a-half. Kinema turns
through the same path smoothly, 7.3° per frame at 0.00 mm error.

On ordinary motion the two are equivalent — properly configured, Blender's IK tracks just as
accurately. The measurement, the fairness rules it follows and the cases where Kinema does
worse are all in tools/demo/.

A pure-NumPy fallback is there for when JAX is unavailable or still loading, and the backend
is switchable per rig.

Bake and deliver. Bake to Keyframes solves the frame range and writes plain FK keys.
After that the .blend animates and renders anywhere — on a farm, on a machine where Kinema
was never installed, with the extension removed entirely.

Honest limitations

• Ball joints are rejected. A 3-DoF spherical joint has no honest single-axis bone
  equivalent, so Kinema says so rather than mis-rigging it. One catalog robot (Cassie) is
  affected; everything else parses.
• PyRoki reads URDF only. MJCF rigs are bridged by rendering the parsed kinematic tree
  back out as a minimal URDF. It works, but it is one more moving part.
• Windows long paths. The bundled wheels unpack into deeply nested directories. On a
  Windows profile without long-path support the install fails partway with WinError 206.
  Enable HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled, or keep
  Blender's config directory shallow. See
  troubleshooting.
• The first IK solve compiles. JAX JITs the solver on first use, roughly 14 s. It is
  paid up front when the IK target is created, behind a wait cursor, and never again for
  that rig. Warm solves are ~5–20 ms.
• MuJoCo's OBJ meshes print MTL errors. MJCF carries its own colours, so the missing
  .mtl files are harmless console noise from Blender's OBJ importer.
• One import at a time. A second import while one is running is refused rather than
  queued.
• Meshes assemble, then snap. They are parented and placed in one pass after the last
  one loads. On a big robot the parts visibly pile at the origin for a second before
  landing.
• Changing the cache location mid-session only affects robots not yet imported; a
  description resolves its path once, at first import.

Downloads and disk

Robot descriptions are cached in ~/.cache/robot_descriptions, shared with
robot_descriptions.py and overridable via ROBOT_DESCRIPTIONS_CACHE or the Robot Cache
preference. mujoco_menagerie is 1.64 GB and backs 49 of the 186 catalog robots, so Kinema
fetches only the subdirectory a given robot needs: a Unitree Go2 costs 31 MB instead of
1.7 GB. A second robot from the same repository is added incrementally.

License

GPL-3.0-or-later, since the add-on links bpy. The vendored PyRoki and jaxls sources remain
MIT; full texts are in LICENSES/.

Full documentation is at https://ebgenius.github.io/kinema/, and the design rules the rig
follows are in the README.