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
This attribute allows specifying the intended output types (e.g., RGB, depth, normal) for each camera in the XML. The output types are stored as bit flags in `mjModel`.
PiperOrigin-RevId: 853316261
Change-Id: I1ad2e94102593cf402756f8f4c80509371ca86d2
`tuple` is better than `list` for constants if we don't expect they get modified by other parts of the code
PiperOrigin-RevId: 838748519
Change-Id: Ic950a78be7ad7518361c046d7e4542607070d3a2
This change introduces a `wrapper_struct_name` function in `structs.py` to consistently generate the name of the C++ wrapper struct from a C struct name. All call sites in `functions.py` and `structs.py` that previously used `common.capitalize` for this purpose now call `wrapper_struct_name`.
PiperOrigin-RevId: 837544242
Change-Id: Ibe5fea8294283dae63bb8d064fd8beb8cfd3f2fe
* Move all bindings into a single EMSCRIPTEN_BINDINGS block
* Move all auto generated bindings line to the start of the block
* Alphabetically sort the constants binding lines
PiperOrigin-RevId: 837142009
Change-Id: I218a37dbc0ca6c6f16a455718889c08fe1b41d56
In `structs.py`, a `RuntimeError` is now raised when an anonymous struct is encountered but is not present in `STRUCTS_TO_BIND`.
PiperOrigin-RevId: 830978376
Change-Id: Id64720a12c3cce313bd513a40a74ddf57718a7d1
Sam Haves