MuJoCo files in a directory containing UTF-8 fail to load (Windows only)

[ft-lab]

Intro

Hi!

I am developing a converter at NVIDIA that converts MuJoCo's XML files to OpenUSD format.

My setup

• MuJoCo 3.5.0
• Python 3.11.13
• Windows 11

What's happening? What did you expect?

Cannot open XML files with UTF-8 characters in their directory names using "bin/simulate.exe".
I am getting the error "ParseXML: Error opening file".

I have confirmed that this also fails with the following mujoco.MjSpec.from_file in Python.

spec = mujoco.MjSpec.from_file(path.as_posix())

Note: This only occurs in Windows environments. I have confirmed that it does not occur on Linux (Ubuntu 22.04).

Steps for reproduction

1. Create a directory named "C:/temp/UTF-8のディレクトリ".
   Please create directory names using multibyte character sets such as Japanese or Chinese.
2. Copy the "model/cube" directory from the MuJoCo repository to this directory.
   The directory structure will be as follows.

  C:
    [temp]
      [UTF-8のディレクトリ]
        [cube]
          [assets]
            blue.png
            ...
          cube_3x3x3.xml
          README.md

3. Launch MuJoCo's "bin/simulate.exe" and drag and drop the xml file from this directory.
4. The following error is displayed, and loading fails.

ParseXML: Error opening file 'C:\temp\UTF-8のディレクトリ\cube\cube_3x3x3.xml'

Minimal model for reproduction

No response

Code required for reproduction

No response

Confirmations

• I searched the latest documentation thoroughly before posting.
• I searched previous Issues and Discussions, I am certain this has not been raised before.

[mar-yan24]

I would like to try and help resolve this issue. I suspect that this bug is caused by the fopen C standard that mujoco uses which defaults to ANSI (not UFT-8 for windows). Linux I'm pretty sure its native. I think it would be best to implement a _wfopen wrapper that replaces the 6 userpath fopen calls. Let me know if this sounds reasonable?

[mar-yan24]

I just implemented a solution and put in a pull request for it. As I suspected, it was the native fopen on windows that does not default to UTF-8. I was able to replicate your issue and fix it using the wrapper I implemented. Hope this helps! 😄

[ft-lab]

Thank you for your prompt response!

I checked PR #3155 .
I was able to confirm that the simulate.exe I built in a Windows environment correctly loaded MuJoCo files on a path containing UTF-8 and referenced stl/obj files.