Out of the box use of bundled plugins when MuJoCo is used as a pure C/C++ library

[traversaro]

Is your feature request related to a problem? Please describe.

I am working on the packaging of MuJoCo 2.3.0 for conda-forge, and I had doubt (that then can be a enhancement proposal, hence the type of issue).

From what I understand, the new plugin system, can be used out of the box in the following contexts:

• When using the Python bindings, as in that case the plugins are loaded by this Python code https://github.com/deepmind/mujoco/blob/2.3.0/python/mujoco/__init__.py#L61
• When using the simulate program, as in that case the plugins are loaded by this C++ code: https://github.com/deepmind/mujoco/blob/2.3.0/simulate/main.cc#L173

Instead, if one is using MuJoCo C++, as of 2.3.0 plugins can not be loaded out of the box, unless copy and adapts the code in https://github.com/deepmind/mujoco/blob/2.3.0/simulate/main.cc#L173 to her/his application. Is my understanding correct? If not, please ignore the rest of the issue, thanks!

Describe the solution you'd like

It would be great if the bundled plugins loaded out of the box also in the C++ library. How to do it is a bit more tricky, basically as long MuJoCo is compiled as a shared library it would be possible to implement a mechanism similar to the one used for simulate, while if MuJoCo is compiled as static library this is not possible, leaving the option either to hardcoded the install path used as compilation, or use an environment variable.

Describe alternatives you've considered

That each executable using MuJoCo implemented its own code to load the bundled plugin, similar to what simulate does.

Additional context

Some interesting pointers on relocatability in C++ libraries can be found in:

• https://indico.cern.ch/event/848215/contributions/3591953/attachments/1923018/3181752/HSFPackagingRelocation.pdf
• https://github.com/drbenmorgan/Resourceful
• Relocatable Gazebo installation gazebosim/gz-sim#626

[saran-t]

The original intention was that if someone is writing a new application that links against MuJoCo then they should decide for themselves how they would like to link and register their plugins. The logic that you point out in simulate is primarily for applications that are supposed to be general, which might expect users to be able to bring precompiled plugins along without having to rebuild the application itself.

Since it's still early days for plugins, I don't know how people will end up using the system. It's possible that the simulate way of working where all plugins in a particular directory are scanned and loaded is more suitable across the board.

We will likely add the loading loop like the one we use in simulate as a MuJoCo API function in our next release. User code will still be responsible for calling the loading loop function however.

[nimrod-gileadi]

Since version 2.3.1, we have the function mj_loadAllPluginLibraries which scans a directory for plugins. Hopefully that solves the issue.