Repository navigation
Releases: ebgenius/kinema
Release list
Kinema v0.6.0
0.5.0 was about the choices inside a job. This release is about the cell around the robot and the tool on it:
- the axes a robot is installed with that its description doesn't have;
- a TCP measured from the mounting flange, the way a tool's CAD is, and placed in a dialog that previews it;
- editing either without waiting on the solver to recompile, and without the robot jumping.
External axes
External Axes → Add External Axis… adds a joint the description doesn't have: a linear track or rotary base under the robot, a tool spindle or slide, or a positioner beside it. It starts from a preset, and every field can be changed. Each axis is an ordinary joint bone, with a slider, a hold pin, limits, a velocity check, keys and bake. PyRoki solves through it on a model written from the rig's own bones.
- Stacking. A new axis under the robot goes in underneath the ones already there, placed from just below the lowest one's rail. A Y track added after an X track carries it, as if the X track were part of the robot.
- What moves. A base or offset that moves the robot carries everything with it, as one rigid move: the axes above, the TCP, the IK target and swivel, keyed goals, the base meshes and the waypoints. Removing the axis, in any order, puts it all back.
- Preview. While the dialog is open, the viewport shows the placeholder, the travel between the end stops, and a ghost of the robot where it will stand. It follows the sliders as they're dragged. Nothing is added until OK, and the dialog keeps its fields if you click away.
Closes #5.
Edit TCP and the mounting flange
A TCP offset of zero is now the mounting flange the description defines: tool0, or a flange turned so its Z points out of the face. A TCP taken from a tool's drawing goes in unchanged, and a fresh import puts the TCP on the flange with zero offsets. On a KUKA KR10 R1100-2 the default TCP used to land on flange, whose approach axis lies in the flange face; it's now on tool0, pointing out of it. Robots without a flange, and rigs imported before this release, still measure from the joint's link frame, so an existing .blend keeps its TCP where it was. Import again to measure from the flange.
Edit TCP…, in the TCP panel, places the TCP by typed offset, on the 3D cursor (snap it to a tool vertex first), or on an object's origin, optionally taking its orientation too. It shows the offset it will store, measured from where the flange is now, so a TCP can be picked off a tool on a posed robot. The viewport previews the new TCP beside the current one as you drag.
No waiting on the solver
Changing the TCP no longer moves the robot or recompiles PyRoki. Re-offsetting the TCP took 5.1 s on the development machine and now takes 0.01 s. The joints stay where they are, and the IK target comes to the new TCP. Removing and re-adding the IK target, or the swivel, keeps the compiled solver too.
Where a new solver is needed, such as a TCP moved to another joint or an external axis added, live IK solves on NumPy until you're done editing, then PyRoki compiles once. Bakes, Find Solutions, playback and rendering always use PyRoki.
Closes #60.
Fixed
- IK with the Root bone posed. Moving or turning Root left the tool off its target by Root's own pose, up to 1.6 m with the robot upside down. It now follows. Closes #61.
Contributing
Bug reports, suggestions and pull requests from forks are welcome. See CONTRIBUTING.md.
Install
Download the zip for your platform and install it in Blender via Preferences → Add-ons → Install from Disk. Requires Blender 5.2 LTS or newer.
On Windows, keep Blender's configuration directory shallow or enable long-path support. The bundled wheels unpack to deeply nested paths, and a deep profile fails partway with WinError 206.
Kinema v0.5.0
0.4.0 taught a robot a job. This release is about the choices inside that job, and whether a real robot could carry it out:
- which of a pose's configurations the arm takes;
- what a rail, a gantry or a seventh axis does while the tool holds still;
- whether the motion is one the robot's motors can follow.
Find Solutions
In the IK panel: the other arm configurations that reach the same tool pose. A six-axis arm can reach one up to eight different ways — elbow bent one way or the other, wrist flipped, base swung round behind. Until now you got whichever one the solver landed on from wherever the arm happened to be.
PyRoki converges to the solution nearest its seed rather than listing branches. So the other solutions are found: seeds scattered across the joint limits, each solved, duplicates folded away. The result is a lower bound, and the panel says so. The ◀ ▶ arrows cycle through what turned up. Applying one only writes joint values, so Key All keyframes it and it bakes like anything else. On a KR120 at a working pose this finds the arm you're in plus the wrist-flipped one, with the tool holding to 0.008 mm across the switch.
Closes #4.
Held joints and the elbow swivel
Held joints, for rails, gantries and turntables. Pin a joint in the Joints panel and IK solves the rest of the chain around it. Move the pinned joint with its own slider or bone, and the tool stays put. Add IK Target pins rails for you: while a chain has more than six unheld joints, its prismatic joints are held, base first. The pin is keyframable, so a rail can be handed back to the solver mid-shot.
An elbow swivel for seven-axis arms. Add Elbow Swivel puts a ring on the shoulder-to-wrist line. Turning it swings the elbow round that line while the tool holds. Its single rotation channel is the elbow's angle, keyed as one curve. On the arm7 fixture the swivel keeps the tool within 0.0003 mm at every strength from 0.5 to 20. The free-floating elbow target it replaces, which never shipped, cost 0.55 mm at the default strength and 30.7 mm at 20.
Closes #48.
Joint velocity limits
A joint moving faster than its limit at the current frame is flagged in red in two places:
- its slider in the Joints panel;
- its own dial or arrow in the viewport, labelled with its speed as a percentage of the limit.
A new Velocity Limits section lists every joint's speed against its limit. Ignore Velocity Limits turns the warnings off for one rig.
The limits come from the description's <limit velocity>. Load Joint Limits… reads a MoveIt or ros2_control joint_limits.yaml over them, joint by joint. A keyed joint is measured exactly, from its own curve, however the frame was reached. A joint driven by live IK is measured against the pose one frame earlier, which playback and stepping provide. Rigs imported before this carry no limits: import them again, or load a joint_limits.yaml.
Addresses #45.
Dependencies
The bundled wheels are now exactly the versions uv.lock pins, and a test fails if the two disagree. They used to be whatever PyPI had newest when the payload was fetched, which is how 0.4.0 shipped lxml 6.1.3 while every test ran against 6.1.2. rospkg moves to 1.6.3.
Install
Download the zip for your platform and install it in Blender via Preferences → Add-ons → Install from Disk. Requires Blender 5.2 LTS or newer.
On Windows, keep Blender's configuration directory shallow or enable long-path support. The bundled wheels unpack to deeply nested paths, and a deep profile fails partway with WinError 206.
Full changelog: https://github.com/ebgenius/kinema/blob/v0.5.0/CHANGELOG.md
Kinema v0.4.0
The KUKA descriptions that would not import correctly, and then the thing that became worth building once they did.
A KR120 imported with its bones up to 5° away from the geometry they were supposed to carry — 0.22 m of error at the flange — because its URDF forbids its own zero pose, which is true of every KUKA quantec. Chasing that turned up two more: link meshes landing with their origins metres underground, and collision geometry that was parsed and then thrown away. With those fixed, the robots stood where their descriptions said, and the question stopped being how do I get this robot into Blender and became what do I want it to do.
Waypoints
The answer to the second question, and the headline here.
Pose the robot and press Record. Each waypoint stores the tool pose and the joint vector it was taught in, because a pose alone does not say which of up to eight solutions you meant — Go To restores that exact configuration instead of re-solving. Every waypoint also gets an Empty in the viewport, so one can be snapped to a feature on the part being worked, and dragging it re-aims the move.
Time is the ordering. A waypoint carries a frame, not a list position, so there is no second order to keep in sync. Each row says how the robot arrives there:
- Joint interpolates the joints. Fast, always reachable, and the tool takes whatever path falls out.
- Linear drives the tool along the straight line between two poses. On a KR120 it holds that line to 0.002 mm over a 300 mm plunge.
Generate Motion writes ordinary keyframes — joint channels for joint moves, the IK goal for linear ones, and the live-IK switch keyed so each span is solved the way it should be. Nothing about the result is special, which is the point: Blender's own graph editor shapes it afterwards, and Bake IK to Keyframes still turns it into plain joint curves that render with the add-on gone.
Collision geometry
Behind a new Import Collision Meshes option, off by default. A URDF describes a robot twice — what it looks like, and the coarse hulls a planner sweeps — and Kinema only ever loaded the first. On a KR120 that is seven STL hulls alongside the visual geometry.
Both kinds now go into their own collection under the robot's, so either can be hidden as a group. Collision starts hidden and draws as wire. For MJCF, geoms in groups 3 to 5 become collision geometry instead of being dropped.
Meshes at File Origin
A checkbox beside Reset Meshes. Improving a robot's geometry means editing a mesh and writing it back as a drop-in replacement for the file the URDF points at — and exporters write world space, so the mesh has to actually be at that file's coordinates. Ticking the box sends every link mesh there; unticking puts them back exactly.
Fixed
Link meshes drifting away from their bones, on any robot whose URDF zero pose its own joint limits forbid — kr120_r2700_2, kr150_r3100_2, the kr210 family, kr240, kr300, kr340, kr500. Meshes were placed by assigning matrix_world, which Blender resolves against the parent bone's evaluated pose, and the limit constraints had already pulled the bones off the rest pose. Placement now comes from each bone's rest matrix.
Link mesh origins now sit on their link frames, instead of metres from their geometry when a URDF authors every mesh in one shared frame.
A warning when a URDF's zero pose is outside a joint's limits, naming the joint, its range, and where the rig will actually rest.
rospkg moves to 1.6.2.
Install
Download the zip for your platform and install it in Blender via Preferences → Add-ons → Install from Disk. Requires Blender 5.2 LTS or newer.
On Windows, keep Blender's configuration directory shallow or enable long-path support: the bundled wheels unpack to deeply nested paths and a deep profile fails partway with WinError 206.
Full changelog: https://github.com/ebgenius/kinema/blob/v0.4.0/CHANGELOG.md
Kinema v0.3.2
Real robot descriptions, from the repositories they actually ship in.
Two of the most widely used ROS description repositories would not import: a KUKA LBR iiwa, because its xacro reaches into a sibling package for its materials, and a Universal Robots arm, because its xacro requires an argument. Neither layout is unusual — that is simply how vendor descriptions are laid out — and behind each was a small stack of further defects that only became visible once the one in front was fixed.
Nothing here changes an existing rig. If your robots already import, this release is about the ones that did not.
Requires Blender 5.2 LTS or newer. Every dependency ships inside the extension zip; nothing is downloaded at runtime.
Download
| Platform | File | Size |
|---|---|---|
| Windows | kinema-0.3.2-windows_x64.zip |
116.5 MB |
| Linux | kinema-0.3.2-linux_x64.zip |
136.4 MB |
| macOS (Apple silicon) | kinema-0.3.2-macos_arm64.zip |
99.7 MB |
Install with Edit → Preferences → Add-ons → Install from Disk.
Added
-
Xacro arguments. A field in the import options — file picker and sidebar both — taking the syntax the
xacrocommand line uses:name:=ur5e ur_type:=ur5e. Some descriptions cannot render without one: the Universal Robotsur.urdf.xacrouses$(arg name)on the line above the one that declares it, so its default never applies and the file will not load unless you supply a name.Pick a
.xacroand the file browser lists the arguments it declares with their defaults, so you can see what it wants before importing rather than after failing. Get one wrong and the error names the argument and lists the rest, instead ofUndefined substitution argument name.The arguments are stored on the rig, because the solver reloads the description later to build its model — a rig that imported cleanly and then quietly lost PyRoki would be a poor trade.
-
Package Search Paths in the preferences: extra directories to find ROS packages in, searched in addition to the repository holding the file. For a cell whose macros live in a different repository from its robots.
Fixed
- Xacro robots that reach into a sibling package now import. A ROS repository puts packages side by side, and a robot in one routinely includes files from another — a KUKA LBR iiwa pulls its materials from
kuka_resourcesnext door. Kinema never told the xacro renderer where those packages were, so any cross-package$(find …)failed withPackageNotFoundErroreven though the package was in the same clone. - Mesh paths in rendered xacros resolved to the wrong place on Windows. Rendering rewrites every
package://into afile://URI, and on Windows the drive letter ends up in the URI's authority rather than its path — so Kinema, reading only the path, got either nothing or a path with the drive removed. It fell back to the description's own directory, which exists, so the robot imported without a single mesh and without an error. - Xacro rigs no longer lose the PyRoki solver. The solver reloads the description to build its model and handed the xacro to the URDF parser unrendered, so
$(arg …)reached a float parser and the rig dropped to the NumPy fallback — silently, because falling back is what happens whenever the reload fails. 38 of the catalogue's robots ship only a xacro. - A package is identified by the name it declares, not the name of its folder.
Universal_Robots_ROS2_Descriptiondeclares itselfur_description, so every$(find ur_description)inside it failed. Both names work, since descriptions in the wild reference either. - A package whose
package.xmlis not plain ASCII no longer breaks the import. It is parsed as XML rather than read with the system codec, so a maintainer's name with an accent stops mattering — on Windows this crashed with'charmap' codec can't decode byte 0x9d.
Changed
- Package discovery is bounded to the checkout. Kinema used to look for ROS packages by scanning several directories above the description, which for a robot saved anywhere near a drive root meant scanning the entire drive — no error, just an import that never finished. It now searches the containing package's parent, stops at a repository boundary, and never walks to a filesystem root.
Full changelog: v0.3.1...v0.3.2
Kinema v0.3.1
A maintenance release. It clears the warning triangle Blender puts on Kinema in Preferences → Add-ons, and changes nothing about using the add-on.
If 0.3.0 works for you, this is not urgent — but the warning it removes is the last thing standing between Kinema and the extensions.blender.org listing.
Requires Blender 5.2 LTS or newer. Every dependency ships inside the extension zip; nothing is downloaded at runtime.
Download
| Platform | File | Size |
|---|---|---|
| Windows | kinema-0.3.1-windows_x64.zip |
116.5 MB |
| Linux | kinema-0.3.1-linux_x64.zip |
136.4 MB |
| macOS (Apple silicon) | kinema-0.3.1-macos_arm64.zip |
99.7 MB |
Install with Edit → Preferences → Add-ons → Install from Disk.
Fixed
-
28 extension policy violations. Blender flags any module loaded from inside an extension's folder that is not named under the extension's own package, and any
sys.pathentry pointing inside it. Kinema tripped both, and they were one decision: the vendored PyRoki and jaxls source was put onsys.pathso it could import under its own top-level names. That produced one warning per vendored module — 13 for jaxls, 14 for pyroki — plus one for the path. Present since 0.2.0.Both packages now import as part of the add-on, so nothing goes on
sys.pathand every module is namespaced. Blender's own checker reports zero warnings where it previously reported 28.This is what the extensions.blender.org review was asking for, and it settles the open question from it: vendored source is allowed — it just has to live under the add-on's own name.
Removed
jaxls/_py310from the vendored payload: 13 files selected bysys.version_infofor Python 3.10 and 3.11, which Blender 5.2's Python 3.13 can never reach.
Under the hood
Nothing here changes behaviour, but it is why this should not regress:
tools/vendor.pyrewrites the vendored packages' absolute self-imports on every vendor run, and refuses to stage a tree where one survives — parsed withastrather than matched with a regex, soimport os, jaxlscannot slip through.- The vendored trees' provenance stamp now records a fingerprint of the whole vendoring recipe, not just the upstream commit. A tree built before a recipe change reads as stale and fails the build, instead of quietly producing a release with the old imports in it.
tests/integration/test_extension_policy.pyasserts the policy rules directly, so a regression fails a test rather than waiting for someone to open Preferences.
Full changelog: v0.3.0...v0.3.1
Kinema v0.3.0
Kinema no longer downloads anything, starts no threads, and writes nothing to your environment.
The robot catalogue stays, and gets better at the part it was always best at — telling you which of 186 robots exists, where it lives and which file to open — but fetching one is now your git clone, not a hidden network call from an add-on. The one visible cost is that importing a robot now blocks Blender while it works.
Requires Blender 5.2 LTS or newer. Every dependency ships inside the extension zip; nothing is installed at runtime.
Download
| Platform | File | Size |
|---|---|---|
| Windows | kinema-0.3.0-windows_x64.zip |
116.5 MB |
| Linux | kinema-0.3.0-linux_x64.zip |
136.4 MB |
| macOS (Apple silicon) | kinema-0.3.0-macos_arm64.zip |
99.7 MB |
Install with Edit → Preferences → Add-ons → Install from Disk.
Changed
- The catalogue is offline. Import from Catalog is now Browse Robot Catalog: search 186 robots by name, maker or category, pick one, and Kinema puts a
git clonecommand on your clipboard along with the pinned revision and the path of the description file inside that repository. Load the file with Import URDF File… as usual.mujoco_menageriealone is 2466 files, so knowing which one to open is the part that actually saves you time. - Curated entries. The catalogue can mark a robot as a duplicate, broken or only partly supported, with a note and a pointer to the entry to use instead. Marked entries are hidden until you tick Show all variants, so searching "UR5e" stops returning three of them.
- Importing a robot blocks. It used to parse on a background thread and build the rig across timer ticks, so the viewport stayed live and Esc could cancel. Extensions may not start threads, and that machinery bought responsiveness and nothing else — so an import is now a wait cursor and a pause: a second or two for an arm, longer for a humanoid, where the time goes on one Blender mesh-importer call per visual.
Fixed
- Importing a xacro failed on Windows, always, with
WinError 32. The renderer handed the parser a temporary file it was still holding open, which Windows will not allow a second handle on. 38 of the catalogue's robots ship only a xacro, so this closed off all of them. Now covered by tests. - Kinema silenced every other add-on's logging. Muting the solver's per-solve output called loguru's
logger.remove(), which drops every sink in the process — including those belonging to other add-ons, since loguru's logger is a process-wide singleton. It now disables just its own vendored packages.
Removed
- The network permission. The extension no longer declares or uses one.
- Every thread, and with them the Preload Solver in Background preference. The solver stack is imported on first use instead, costing 2–5 s once per session at the first solve.
- Every environment variable Kinema set:
JAX_PLATFORMS,JAX_ENABLE_X64andROBOT_DESCRIPTIONS_CACHE. 64-bit mode moved tojax.config.updateafter the import; the CPU pin turned out to have nothing to pin, since only the CPUjaxlibwheels are bundled; and the cache variable went with the Robot Cache preference, also gone. - Ten wheels.
robot-descriptions,GitPython,gitdbandsmmapwent with the downloading catalogue.packaging,setuptools,docutils,pyparsing,tqdmandtypeguardsatisfied nothing at all — nothing in Kinema or the vendored solver imports them, and nothing requires them. The payload is 38 wheels, down from 48 — 28 per platform, since five are compiled once each for Windows, Linux and macOS.
Upgrading
Rigs built by 0.2.0 or earlier from the downloading catalogue will report that their description can no longer be reloaded; re-import it from disk to restore the PyRoki solver. Rigs imported from a local file are unaffected.
Full changelog: v0.2.0...v0.3.0
Kinema v0.2.0
Dressing and aiming. A robot can now carry the things that make it a working cell — a gripper, a tool, a cable harness — and the solver can be pointed at any bone in the chain, keyframe included. The tool frame became something you place and offset from the panel rather than something you fight in Edit mode.
Requires Blender 5.2 LTS or newer. Every dependency ships inside the zip.
Attachments
A new Bones list in the sidebar, one row per bone. Pick an object or a collection in a row and a linked copy rides that bone — a gripper on the flange, a harness down the forearm. It shares mesh and materials with the source, so the same model can dress six links and still be edited in one place, and the source may live in any scene in the file.
Offsets are measured from the bone's head, not the tail Blender's own bone parenting uses, so the attachment's plain location/rotation/scale is its offset from the joint — editable in the sidebar or with G/R/S, and keyframable.
Aim IK at any bone, and keyframe which one
The radio button in each row points the solver at that bone. On a redundant robot this is the difference between a working setup and a puzzling one: a Panda imports with its tool frame on a fingertip, leaving both gripper joints in the chain — 9 DoF against a 6-DoF task — so the solver holds the fingertip still while spinning the hand around it. Aim at the flange and the chain is the seven arm joints it should be.
The choice is keyframable, so a shot can hand the goal from the wrist to the elbow part-way through. Baking follows it.
A tool frame you can place
The Tool Centre Point panel gains a parent-bone field and six offset fields — location and roll/pitch/yaw, in the flange's own link frame and in URDF's <origin rpy> convention, so a tool transform copied out of a description goes in unchanged. Mounting a tool 150 mm off the flange no longer means adding a bone by hand in Edit mode. The panel reports the tool's orientation beside its position, and the marker's approach axis is drawn arrowed so you can see which way it faces.
Fixes worth knowing
- Clicking Move TCP to Active Bone raised an
AttributeErroron a freshly imported rig. It could not work from Object mode at all. - A mesh file's own units and up-axis were discarded, so a millimetre COLLADA imported a thousand times too large and a Y-up one lay on its side.
- A URDF
<mesh scale>was left in the object's scale instead of applied, so modifiers, physics and exporters quietly used the unscaled mesh.<mesh scale="0.001"/>— the single-value shorthand — aborted the import outright. - A link mesh nudged by accident could not be put back. Rest Pose only returns the joints. There is now a Reset Meshes button beside it, and link meshes are locked.
- Re-placing the TCP no longer flips its orientation.
The full list is in CHANGELOG.md.
Install
Download the zip for your platform below and drag it into Blender, or Edit ▸ Preferences ▸ Add-ons ▸ Install from Disk. See the install guide.
| Platform | File | Size |
|---|---|---|
| Windows (Intel/AMD 64-bit) | kinema-0.2.0-windows_x64.zip |
~119 MB |
| Linux (Intel/AMD 64-bit) | kinema-0.2.0-linux_x64.zip |
~139 MB |
| macOS (Apple Silicon) | kinema-0.2.0-macos_arm64.zip |
~102 MB |
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 withWinError 206.
EnableHKLM\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
.mtlfiles 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.