chenlin/Mujoco_WASM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'google-deepmind:main' into mjx-warp-segmentation

Browse Source
This commit is contained in:
Tarik Kelestemur
2026-04-26 21:36:32 -04:00
committed by GitHub
parent 22f4458b1c b643f50b2a
commit 1009478de9
75 changed files with 2344 additions and 1124 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/APIreference/APIglobals.rst
+1 -1
View File
@@ -388,7 +388,7 @@ Defined in `mujoco.h <https://github.com/google-deepmind/mujoco/blob/main/includ
- value
- description
* - ``mjVERSION_HEADER``
- 3007001
- 3008001
- The version of the MuJoCo headers. This is an integer calculated from the version string "S.M.P"
using the formula ``(S * 1e6) + (M * 1e3) + P``. For example, version 4.2.1 is represented as 4002001.
The API function :ref:`mj_version` returns a number with the same meaning
doc/changelog.rst
+24 -17
View File
@@ -2,34 +2,41 @@
Changelog
=========
Upcoming version (not yet released)
-----------------------------------
Version 3.8.0 (April 24, 2026)
------------------------------
General
^^^^^^^
- Added new :ref:`mj_maxContact<mj_maxContact>` function to get the maximum number of possible contacts returned by
two geoms.
- Added ``mj_containsBufferVFS`` and ``mj_containsFileVFS`` to check for existence of buffers and files in VFS.
- Added :ref:`multi-cell support<body-flexcomp-cellnum>` for trilinear and quadratic flexes. Note that the implicit
integrator uses a dense solver for the flex degrees of freedom, which can be slow for multi-cell flexes.
- Refactored ``flexstrain`` equality constraints to be instantiated per cell instead of per flex object, reducing the
number of degrees of freedom per constraint row. The equality can be associated with a specific cell with the new
attribute ":ref:`cell <equality-flexstrain-cell>`
1. Added support for Python 3.14.
2. Added :ref:`multi-cell support<body-flexcomp-cellcount>` for trilinear and quadratic flexes. Note that the implicit
integrator uses a dense solver for the flex degrees of freedom, which can be slow for multi-cell flexes.
3. Refactored ``strain`` flex :ref:`equality constraints<flexcomp-edge-equality>` to be instantiated per cell instead of
per flex object, reducing the number of degrees of freedom per constraint row. The equality can be associated with a
specific cell with the new attribute :ref:`cell <equality-flexstrain-cell>`
4. Added new :ref:`mj_maxContact<mj_maxContact>` function to get the maximum number of possible contacts returned by
colliding two geoms.
5. Added ``mj_containsBufferVFS`` and ``mj_containsFileVFS`` to check for existence of buffers and files in VFS.
.. admonition:: Breaking API changes
.. admonition:: Breaking API changes
:class: attention
- The feature :ref:`multiccd<coMultiCCD>` is now enabled by default. This feature has little performance overhead
and gives better contact behavior for stability.
6. The :ref:`multiccd<coMultiCCD>` option (multiple contacts returned from the convex collision detection pipeline)
is now enabled by default. The new implementation (as opposed to the legacy pipeline) has little performance
overhead and improves stability.
**Migration:** The flag :ref:`multiccd<option-flag-multiccd>` must be explicitly disabled.
**Migration:** Disable :ref:`multiccd<option-flag-multiccd>` to recover the previous behavior.
Documentation
^^^^^^^^^^^^^
7. Added :ref:`documentation<exDecoder>` for :ref:`mjpDecoder` plugins.
Bug fixes
^^^^^^^^^
- Asset paths in attached child specs are now resolved relative to the model file directory of the child spec, rather
than the parent spec. This prevents the origin of the parent spec to affect the resolution of asset paths in the child
spec.
8. Asset paths in attached child specs are now resolved relative to the model file directory of the child spec, rather
than the parent spec. This prevents the origin of the parent spec to affect the resolution of asset paths in the
child spec.
Version 3.7.0 (April 14, 2026)
------------------------------
doc/programming/extension.rst
+135 -2
View File
@@ -3,8 +3,8 @@
Extensions
----------
This section describes MuJoCo's mechanisms for user-authored extensions. At present, extensibility is provided
via :ref:`engine plugins<exPlugin>` and :ref:`resource providers<exProvider>`.
This section describes MuJoCo's mechanisms for user-authored extensions. At present, extensibility is provided by
via :ref:`engine plugins<exPlugin>`, :ref:`decoders<exDecoder>`, and :ref:`resource providers<exProvider>`.
.. _exPlugin:
@@ -337,6 +337,139 @@ For the sdf plugin, the following methods need to be specified
Computes the axis-aligned bounding box in local coordinates. This volume is voxelized uniformly before the call to
the marching cubes algorithm.
.. _exDecoder:
Decoders
~~~~~~~~
Decoder plugins extend asset loading capabilities beyond MJCF and URDF. They are :ref:`registered<mjPLUGIN_LIB_INIT>`
similarly to other MuJoCo plugins.
MuJoCo ships with two built-in decoders for common mesh formats:
- **OBJ decoder** (``plugin/obj_decoder``) -- `Wavefront OBJ <https://en.wikipedia.org/wiki/Wavefront_.obj_file>`_.
- **STL decoder** (``plugin/stl_decoder``) -- `STL <https://en.wikipedia.org/wiki/STL_(file_format)>`_.
Additionally, we provide the following optional decoder plugins:
- **USD decoder** (``plugin/usd_decoder``) -- `Universal Scene Description <https://openusd.org/release/index.html>`_.
These plugins also serve as examples for how to write custom decoders. The obj decoder is perhaps the simplest to
understand, while the USD decoder is more complex due to its support for entire scenes.
.. _exDecoderInterface:
Decoder interface
^^^^^^^^^^^^^^^^^
A decoder is described by the :ref:`mjpDecoder` struct, which has the following fields:
``content_type``
A MIME-like content type string identifying the format. For example, ``"model/obj"``, or ``"model/stl"``.
When a mesh asset specifies a ``content-type`` attribute in MJCF, this string is used
to find the appropriate decoder.
``extension``
A file extension string (including the dot) used for matching when no content type is specified. Multiple
extensions can be separated by pipes (`|`) for formats with multiple extensions such as ``.usd|.usda|.usdc|.usdz``.
``can_decode``
A callback of type :ref:`mjfCanDecode` that determines whether the decoder can handle a given resource. This is
typically implemented by checking the file extension but may also check the file contents to differentiate between
formats. For example, URDF and MJCF files both have a ``.xml`` extension. Returns nonzero if the decoder can handle
the resource.
``decode``
A callback of type :ref:`mjfDecode` that performs the actual decoding. It receives an :ref:`mjResource` and
returns a newly allocated :ref:`mjSpec` containing the decoded asset data. The caller takes
ownership of the returned spec and is responsible for freeing it with :ref:`mj_deleteSpec`. Returns ``NULL`` on
failure.
When a decoder is invoked for a mesh asset, the compiler will reference the first mesh element in the spec returned
by the ``decode`` callback.
When a decoder is invoked for a model asset, the spec returned by the ``decode`` callback may contain any number of
elements of any type.
.. _exDecoderRegistration:
Registration
^^^^^^^^^^^^
Decoders must be registered before they can be used. Registration is performed via
:ref:`mjp_registerDecoder`. The :ref:`mjp_defaultDecoder` function initializes an :ref:`mjpDecoder` struct with
default values. The :ref:`mjPLUGIN_LIB_INIT` macro is used to define the initialization function that registers the
decoder when the library is loaded.
.. code-block:: C
mjPLUGIN_LIB_INIT(my_format_decoder) {
mjpDecoder decoder;
mjp_defaultDecoder(&decoder);
decoder.content_type = "model/my-format";
decoder.extension = ".myf|.myfa|.myfc";
decoder.decode = MyDecode;
decoder.can_decode = MyCanDecode;
mjp_registerDecoder(&decoder);
}
.. _exDecoderExample:
Example
^^^^^^^
Below is a minimal decoder that reads a hypothetical binary mesh format:
.. code-block:: C
#include <mujoco.h>
static mjSpec* MyDecode(mjResource* resource, const mjVFS* vfs) {
const void* bytes = NULL;
int nbytes = mju_readResource(resource, &bytes);
if (nbytes < 0) {
mju_warning("failed to read resource '%s'", resource->name);
return NULL;
}
/* ... parse bytes into vertex/face arrays ... */
mjSpec* spec = mj_makeSpec();
mjsMesh* mesh = mjs_addMesh(spec, NULL);
mjs_setString(mesh->file, resource->name);
mjs_setFloat(mesh->uservert, vertices, nvert * 3);
mjs_setInt(mesh->userface, faces, nface * 3);
return spec;
}
static int MyCanDecode(const mjResource* resource) {
/* check file extension */
const char* name = resource->name;
int len = strlen(name);
return len > 4 && strcmp(name + len - 4, ".myf") == 0;
}
mjPLUGIN_LIB_INIT(my_format_decoder) {
mjpDecoder decoder;
mjp_defaultDecoder(&decoder);
decoder.content_type = "model/my-format";
decoder.extension = ".myf";
decoder.decode = MyDecode;
decoder.can_decode = MyCanDecode;
mjp_registerDecoder(&decoder);
}
Once registered, the decoder is used automatically when MuJoCo encounters an asset with a matching file extension
or content type:
.. code-block:: xml
<asset>
<mesh file="my_mesh.myf"/>
</asset>
.. _exProvider:
Resource providers
doc/unity.rst
+2 -2
View File
@@ -37,14 +37,14 @@ _____
The MuJoCo app needs to be run at least once before the native library can be used, in order to register the library as
a trusted binary. Then, copy the dynamic library file from
``/Applications/MuJoCo.app/Contents/Frameworks/mujoco.framework/Versions/Current/libmujoco.3.7.1.dylib`` (it can be
``/Applications/MuJoCo.app/Contents/Frameworks/mujoco.framework/Versions/Current/libmujoco.3.8.1.dylib`` (it can be
found by browsing the contents of ``MuJoCo.app``) and rename it as ``mujoco.dylib``.
Linux
_____
Expand the ``tar.gz`` archive to ``~/.mujoco``. Then copy the dynamic library from
``~/.mujoco/mujoco-3.7.1/lib/libmujoco.so.3.7.1`` and rename it as ``libmujoco.so``.
``~/.mujoco/mujoco-3.8.1/lib/libmujoco.so.3.8.1`` and rename it as ``libmujoco.so``.
Windows
_______