This change introduces new functions to load an `mjModel` from an XML string. Two overloads are provided: one that creates a temporary VFS and one that uses a MjVFS arg.
Also updated other places where `from_xml_string` should be used: demos, readme, etc.
PiperOrigin-RevId: 882581762
Change-Id: I8428196f8f56ae9630fcd4f0bb6763cdc1c43da0
Introduces `from_xml_path` and `from_binary_path` as more idiomatic aliases for `mj_loadXML` and `mj_loadModel` respectively. Refactors the binding of `mj*STRING` constants. Instead of exposing `get_mj*STRING` functions, these constants are now available as properties on the `Module` object. Runtime getters are added via EM_ASM to lazily call the underlying C++ functions.
PiperOrigin-RevId: 882566011
Change-Id: Id3bd5c23704fd122af30a50aed089bd3143fbc96
This change updates the Emscripten build to output files named `mujoco.js`, `mujoco.wasm`, and `mujoco.d.ts` instead of `mujoco_wasm.*`. The internal CMake target name remains `mujoco_wasm` to avoid conflicts. The package name in `package.json` is also updated to `mujoco`. New enum tests are added.
PiperOrigin-RevId: 875140314
Change-Id: Ie03e0d1db2d03dd8582d5bfcb260b3d33549c2c9
--
b1734da56e293b50e7bd0cc8b9a8ee5677aa70ec by MatiasManevi <manevimatias@gmail.com>:
Improve wording for WASM Windows support status
COPYBARA_INTEGRATE_REVIEW=https://github.com/google-deepmind/mujoco/pull/3095 from MatiasManevi:wasm-readme b1734da56e293b50e7bd0cc8b9a8ee5677aa70ec
PiperOrigin-RevId: 869699309
Change-Id: I2780d2406139e33eeb5521f509245d29b69a61ab
Adds a test which verifies that we can index into the texture buffer at offsets larger than can be represented by a 32-bit signed int.
PiperOrigin-RevId: 868756646
Change-Id: Ibc1a2b269fce41aec370611b0aab77803837e7a8
The link to the named access tests in `tests/bindings_test.ts` was incorrectly formatted.
PiperOrigin-RevId: 862786877
Change-Id: Idf10d75638e55b7d3b0312c765a977274d014857
This change updates all size-related members within the `mjModel` struct from `int` to `mjtSize`. This allows MuJoCo to handle models with a larger number of elements. Corresponding changes were made to macros, function signatures, and I/O routines to accommodate the new `mjtSize` type.
PiperOrigin-RevId: 860144595
Change-Id: I701c6d607715d240766b6210a9773cd9e4258c59
This change adds an Emscripten binding for loading binary MuJoCo models (`.mjb`) from the virtual filesystem. The new binding, `mj_loadBinary`, takes a filename and an `MjVFS` object, enabling the loading of models that reference assets within the VFS.
PiperOrigin-RevId: 859740455
Change-Id: I9f9d8bbba0b57422e2356867e4282a1b04566475
Most of it is done leveraging existing X Macros (indexers.h, indexer_xmacro.h) used for python bindings already.
PiperOrigin-RevId: 856205245
Change-Id: Ic72443999065040af3042bbf3f9f68c5b70d309d
Regarding mj_compile VFS argument:
I was encountering a memory error when using `std::optional<MjVFS>` with `mj_compile` (because vfs should be an optional argument of the function). This is likely because `MjVFS` doesn't have copy/move constructors, which are required for types used with `std::optional`, causing issues with memory management when std::optional copies the MjVFS object.
To solve this and to make vfs an optional argument to `mj_compile`, I replaced `mj_compile_wrapper` with two overloaded functions. This avoids using `std::optional<MjVFS>` and resolves the memory issue, while still allowing mj_compile to be called with or without the vfs argument from JavaScript.
But what if we instead add those copy/move constructors so it works with `std::optional`?:
While making `MjVFS` copyable or movable would theoretically allow it to work with std::optional, it's not a feasible approach in this case.
The MjVFS struct manages file data in memory, allocating buffers when files are added and freeing them when `mj_deleteVFS` is called in its destructor. A copy would require a deep copy of the entire virtual filesystem, but MuJoCo does not provide a public API function (like a "mj_copyVFS") to do this. Implementing a deep copy manually would be complex and fragile. A shallow copy would result in multiple MjVFS objects pointing to the same memory, leading to double-free errors when their destructors run.
Given these constraints, MjVFS cannot safely be made copyable. The approach of providing two overloaded C++ functions is better.
PiperOrigin-RevId: 855740541
Change-Id: Ia08b6db8868ad245f07145db3fb0322cb9f737cb
Google DeepMind