All known implementations were effectively the same as the default fallback. It was just adding unneeded complexity. Removing this now will help with upcoming improvements to resource providers.
PiperOrigin-RevId: 855163273
Change-Id: I529fc18d0d03a8dc676c909ec9e4b1da1454d414
Updates function comments to consistently use a semicolon (`;`) before describing the return value and to use the imperative form "return" instead of "returns".
Also fix error in docstring of `mjp_registerResourceProvider`
PiperOrigin-RevId: 854888532
Change-Id: I311239a2770ded5febece9958ae4e94c1e522600
Add usd_decoder to mujoco/plugin.
- Previously was src/experimental/usd/usd_to_mjspec.cc, now that same spec is returned by the plugin.
PiperOrigin-RevId: 854350962
Change-Id: Ia980190a557c50ce8197980922a2594b613859b4
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
This change makes `mjtSize` a signed, rather than unsigned 64-bit integer. While sizes are non-negative, the type promotion rules for unsigned integers can lead to unituitive downstream bugs, and 8 billion terabytes are enough bytes.
PiperOrigin-RevId: 834292964
Change-Id: Iea9c47c2a5d80fde63851a543d59ed0549db0f01
This enables two workflows:
1) Users that parsed some other format into MjSpec, or built it programmatically can export animated USD easily with as minimal as possible interaction with USD.
2) Creating a spec from USD, then modifying the spec, should not cause a duplication of data when writing to USD.
PiperOrigin-RevId: 827627520
Change-Id: I02c8c14a18569547710e54f3704d52ac0bf70ce6
- plugin system similar to mjpResourceProvider, but instead of loading a resource it converts an existing mjResource into an mjSpec.
- The returned spec is then composed into the referencing spec.
- This enables different file types to generate arbitrary specs, and allows us to separate format parsing from compilation code.
Follow up CLs will move some of the logic in src/engine for PNG, USD, KTX, OBJ loading into decoders.
The mj_parse function MjSpec from a given file, it's a more generic version of mj_parseXML.
In it's implementation, mj_parse as opposed to mj_parseXML will look for any registered decoder and
not assume we are striclty dealing with MJCF.
PiperOrigin-RevId: 826149497
Change-Id: I0ece26904280cb94bd5ded6dd5a565c539d60254
This function allows the caller to extract a subset of components of a state previously obtained via `mj_getState` without having to first write it back into `mjData`.
PiperOrigin-RevId: 822165077
Change-Id: I6433261f4f5ec2e8d024bb7dee8f7dbf1e62666c
*** Reason for rollback ***
BEGIN_PUBLIC
Holding off on a minor version bump until the next release.
*** Original change description ***
#mujoco update the version to 3.4.0 ahead of the 3.4.0 release.
Bump the version to 3.4.0 ahead of the next release.
***
PiperOrigin-RevId: 818748143
Change-Id: I722e9beb80c61a48bd997da6a1840777a81d5036
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
Haroon Qureshi