The dense Jacobian arrays `J0_dense` and `J1_dense` are now zeroed only once before the vertex loop. Inside the loop, only the entries that were actually used are zeroed out after being added to the sparse Jacobian, allowing for efficient reuse of the dense arrays across all vertices.
PiperOrigin-RevId: 860799056
Change-Id: Ia61daae5eeb2f4dbc0c5d8c0064622a881e92b7a
Use unsigned size_t instead of signed mjtSize for size multiplications to avoid Clang's overflow-checking intrinsic. This is semantically correct as size calculations are inherently unsigned.
PiperOrigin-RevId: 860213177
Change-Id: I837aa6556335478969d4977492d0f231419f020a
Use unsigned size_t instead of signed mjtSize for size multiplications to avoid Clang's overflow-checking intrinsic. This is semantically correct as size calculations are inherently unsigned.
PiperOrigin-RevId: 860172221
Change-Id: I3b6cb720db8771b8f266f1927e2980ac7514538b
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
There are three ways to load a model: from a file, from a buffer, or an
"empty" model. Instead of overloading a single function to do all three,
provide three separate functions.
Also disable model loading functions that will not work for emscripten.
PiperOrigin-RevId: 859051341
Change-Id: I71557d31d0e7c9c6882895c36116d300f19e255d
The ImGui table API cell padding variables can be used to adjust the positioning of the UI in the box.
PiperOrigin-RevId: 858137824
Change-Id: I1ce1519c0abd67bc5fafc30f9a18dfcf18c2a313
This change introduces two new USD API schema:
* MjcEqualityAPI - base API for representing MuJoCo equality constraints in USD, this will typically be applied to joints such as UsdPhysicsFixedJoint.
* MjcEqualityWeldAPI - extends MjcEqualityAPI for MuJoCo's weld equality constraints with an attribute for torqueScale.
The usd_decoder is updated to parse UsdPhysicsFixedJoints and convert the new schema attributes into the appropriate mjsEquality data fields.
PiperOrigin-RevId: 856723634
Change-Id: I0982fd3168b643f8e91d87bb5ae5933e526b63a1
Adds a new window that allows the user to display one or more renders from
the different cameras in the scene.
PiperOrigin-RevId: 856607089
Change-Id: I7268ffd3ef62b9b4d62ce8d004fdbbec92b42af4
Since relationships in USD can only contain a single instance of a path, it was previously impossible to have a tendon path that visits the same wrap target more than once. This is a fairly common occurence when dealing with tendons that have pulleys.
With this change, if mjc:path:indices is not defined then the behaviour is as it was and the mjc:path is considered to be ordered. If it is authored then the parser will use the indices into mjc:path as the order. This mirrors other similar concepts in USD such as face vertex indices.
PiperOrigin-RevId: 856339887
Change-Id: I6b9503973de377acdb0689be168c16e4aa19b70b
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
Resource operations (e.g. mju_openResource, mju_readResource, and
mju_closeResource, etc.) are now all handled by a VFS instance. It
is now up to the VFS to determine which provider to use in order to
handle those operations.
This allows us to dynamically add/remove (aka "mount") providers to
a VFS to handle special requests. mj_addFileVFS and mj_addBufferVFS
have been reimplemented as two such use-cases. Moreover, we expose
the mounting behaviour with two new functions: mj_mountVFS and
mj_unmountVFS.
PiperOrigin-RevId: 856166919
Change-Id: Id723d612ffc0bff020705cf19ef95fbf24676840
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
Haroon Qureshi