For example when loading parent_merge.xml:
```
WARNING: Attach conflict when attaching 'child' to 'parent_merge', policy is 'merge'
timestep: parent has 0.005, child has 0.002, taking the minimum
iterations: parent has 50, child has 100, taking the maximum
flag 'Damper': added from child
```
When loading parent_error.xml:
```
XML Error: Attach conflict when attaching 'child' to 'parent_error', policy is 'error'
timestep: parent has 0.005, child has 0.002
iterations: parent has 50, child has 100
Element 'attach', line 10
```
PiperOrigin-RevId: 933620810
Change-Id: Ib477863b5ef763474d27fb4be5a4148be1d5d500
Compiler warnings are now accumulated in a vector of strings within the mjSpec object. New API functions `mjs_numWarnings` and `mjs_getWarning` are added to access these warnings. The compiler's log handler now chains warnings to the global log handler, ensuring they are still displayed immediately. Call sites in `mj_loadXML`, `mj_compile`, and the Python and WASM bindings have been updated to use the new warning API.
PiperOrigin-RevId: 933361650
Change-Id: I47cab98a460c57b0898c0a1a43fce2a5b9648eb1
For example, `compile mujoco_menagerie/robotis_op3/scene.xml` now outputs
```
Compile 1 (cold cache):
total: 317.2 ms
assets: 284.8 ms (wall clock)
load: 616.1 ms
hull: 26.4 ms
poly: 137.8 ms
inert: 177.8 ms
bvh: 568.2 ms
octr: 1.6 ms
tex: 25.3 ms
other: 32.4 ms
Compile 2 (warm cache):
total: 79.9 ms
assets: 54.5 ms (wall clock)
load: 888.5 ms
hull: 0.0 ms
poly: 0.0 ms
inert: 0.0 ms
bvh: 0.0 ms
octr: 0.0 ms
tex: 21.4 ms
other: 25.3 ms
```
PiperOrigin-RevId: 917850214
Change-Id: Iaec86230bec0faf2e47820e20cbff61de5b2621e
The new function mjs_getOriginSpec returns the mjSpec that was used to define a given mjsElement. Unlike mjs_getSpec, this value remains constant even after the element has been attached to a different model.
PiperOrigin-RevId: 911930951
Change-Id: Ia9cd79d9dfabc513d6121eadcffc5d41075224c9
Previously specs that were attached to some parent spec would resolve its asset paths relative to the modelfiledir of the parent spec. This means path resolution would change depending on the source of the parent spec. Instead, this change makes asset file path resolution relative to the "owning spec" i.e. the spec where the asset was created.
This enables workflows such as loading a parent spec via resource provider, then loading a child spec via `from_zip` or in memory providing `spec.assets` and resolution will work as intended.
PiperOrigin-RevId: 903207910
Change-Id: Ia58020ab372a3ceadf31e804d145e2ae53d8e5f9
This change disallows calling `mjs_delete` on an mjSpec that has been attached to another mjSpec via `mjs_attach`. Attempting to delete an element from an attached spec will now result in an error. The Python bindings for `mjSpec.delete` have been updated to raise a ValueError when this occurs.
PiperOrigin-RevId: 897266695
Change-Id: Ic0670125a3028191ec50eca890f02b5910ec8b03
- Remove `lugre:viscous`, should now be added directly to actuator `damping`. Trying to do this for the user was incompatible with default inheritance (compounding instead of overriding).
- Move voltage limiting from the `saturation` to the `controller` attribute.
- Fix indexing issues in default inheritance.
PiperOrigin-RevId: 897087642
Change-Id: I5388c2633e15c7e223992e7eb5d6a28db75a6438
MujocoTest now loads plugins from MUJOCO_PLUGIN_DIR if set.
PluginTest is removed; all tests use MujocoTest directly.
testspeed binary loads plugins from MUJOCO_PLUGIN_DIR.
This is in preparation for moving common asset format parsing (obj, msh, stl, etc.) where we will always want to load those plugins.
PiperOrigin-RevId: 874194428
Change-Id: Id90805a9ba5de4627911b56d8b9c4ab4e1b29310
For backwards compatibility in the Python bindings, both `spec.compiler.meshdir` and `spec.meshdir` are now allowed.
Fixes#2834.
PiperOrigin-RevId: 809060113
Change-Id: Ie23f1c5dd57de43568312a8e062906f4013bb474
In a follow-up, mjs_detach will be changed to only remove without deleting an element.
PiperOrigin-RevId: 773637351
Change-Id: I9ee4d3584ba88ccc225591337cf036bab806e25c
For the MJCF -> USD plugin, and I suspect other usecases for user values, it's necessary to give ownership of the object to Mujoco. However since they get type erased, we can't clean up the data automatically for the user. Instead this allows c++ clients to provide a cleanup function with their data.
PiperOrigin-RevId: 756832010
Change-Id: I80b8e7822e1a0e399a0d19dcaa57ee69b3ccc16a
The signature now contains the necessary information to safely perform `bind`. The private UIDs are now removed.
Fixes an issue of changing signature when compiling a copy of an mjSpec.
PiperOrigin-RevId: 744670626
Change-Id: Id3c66419cf2afbe78e91bc4b37d2299f5ec00ab1
Previously, we stored the source `mjSpec` during a copy as a hack for having access to the compiler options, but this is not robust since we cannot guarantee that 1) the source `mjSpec` is not destroyed before we need to look up the compiler options nor 2) that the `mjSpec` was appended without a copy.
While 2) could be solved by simply handling an additional case in `mjCModel::FindSpec`, using a map also solves 1) and it is easier to understand.
PiperOrigin-RevId: 741504264
Change-Id: Iab1bfd9e61299a94fa8caf3a244c067b09d54384
Fixes#2497.
Also, use `Release()` instead of `delete` for removing elements when detaching a body in order to preserve correct reference count.
PiperOrigin-RevId: 739133888
Change-Id: I7ccfad84446fb15259bad30c4ba1e6f7fa601518
This is required in preparation of changing the spec.attach behavior in the Python bindings.
PiperOrigin-RevId: 730810198
Change-Id: I095808f0afe62b5bbd27201ed5c75804e0e9c4bf
Sam Haves