dm_control
dm_control copied to clipboard
Respect MJCF path processing and XML include specifications
From the MuJoCo docs:
The full path to a file is determined as follows. If the strippath attribute described above is "true", all path information from the file name is removed. The following checks are then applied in order: (1) if the file name contains an absolute path, it is used without further changes; (2) if this attribute is set and contains an absolute path, the full path is the string given here appended with the file name; (3) the full path is the path to the main MJCF model file, appended with the value of this attribute if specified, appended with the file name.
This is applies to included files, which must be treated as if they were part of the document including them. dm_control.mjcf
, however, ignores this and treats all paths relative to the file(s) being included.
Take the following example:
/root/foo.xml
<mujoco>
<compiler texturedir="textures" />
<include file="common/skybox.xml" />
...
</mujoco>
/root/common/skybox.xml
<mujoco>
<asset>
<texture name="skybox" type="skybox"
fileright = "skyboxes/right.png" <!-- /root/textures/skyboxes/right.png -->
...
/>
</asset>
</mujoco>
This example (were it filled out entirely) compiles successfully using MuJoCo, but fails when using dm_control.mjcf
which looks for right.png
in /root/common/skyboxes/
. It appears the root problem is in parser.py
which doesn't propagate the the fact that skybox.xml
was included.
This means the MJCF models in dm_control are incompatible with other MuJoCo-dependent libraries and vice-versa.
I'm working with complex models with multiple includes and assets that work just fine in MuJoCo but isn't compatible with pyMJCF. This seems particularly problematic when assets are managed by included XML files. Attaching a stand-alone example that can be executed by python dm_mjcf.py
furniture_sim.zip