MuJoCo, from Elixir.

{:ok, model} = ExMujoco.load_xml("model/scene.xml")
data = ExMujoco.data(model)

ExMujoco.forward(data)
ExMujoco.step(data)

ExMujoco.Data.qpos(data) |> ExMujoco.Tensor.to_list()
ExMujoco.Model.geom_size(model) |> ExMujoco.Tensor.to_list()

A model is compiled and immutable; a data block is the state that moves. Both are resources, released by the garbage collector, so there is no lifetime to get wrong: a Data holds the Model it came from, and neither outlives its user.

Fields are read one at a time — ExMujoco.Model and ExMujoco.Data have a function per field of mjModel and mjData, named as MuJoCo names them, and answering either a number or an ExMujoco.Tensor. Reading copies, so what you hold does not change when the next step runs.

Where the code comes from

The NIF is generated from MuJoCo's own headers: one binding per field and per C function in c_src/manifest.exs. docs/coverage.md says what is bound and what is not, and why. The hand-written half — c_src/ex_mujoco_nif.cpp — is the part where each call needs a decision: which buffer, whose lifetime.

What is not here yet

mjSpec — building a model in memory, rather than compiling XML — and offscreen rendering. Both are in docs/plan.md with the reason they are their own phase: a scene needs a GL context per platform, and that is a different job from stepping physics.

Errors

MuJoCo reports a fatal error by not returning, which inside a NIF would abort the VM. It is intercepted and arrives as ExMujoco.Error with MuJoCo's own message, so a bad model is an exception in one process and not a dead node.