Is it possible to skip loading meshes that is only used for visualization if `discardvisual` is enabled?

[JewelryForge]

Is your feature request related to a problem? Please describe. Hello! I'm trying to use mujoco for legged control with reinforcement learning. I want to build massively parallel environments, e.g. 1024 independent mujoco models & data like Isaac sim, to collect experience. During training, discardvisual should be enabled to remove visual-only parts to save memory and accelerate simulation. It's common for legged robots to use only simple geometry shapes like boxes or spheres instead of meshes to represent the collision of the robot. So, as for training, it's desired to skip the time-consuming mesh loading, instead of loading and then discarding them.

Describe the solution you'd like Currently, in mjCModel::Compile, meshes are first compiled for calculating dependent properties like bvhs of bodies, although they are probably unused. An immature idea would be to split the compilation of each element into two parts, with the first part simply looking for references to the relevant element, i.e. ResolveReferences, and the second part doing the rest of the compilation tasks. If discardvisual is enabled, in the middle of the two parts, the isVisual option for each geom and mesh could be flagged and the visual-only parts discarded.

Describe alternatives you've considered I guess the need is niche and low priority. Now my solution is to prepare two versions of model file. One contains visual parts and the other is simplified to contain collision parts only.

Additional context Compiling a unitree_g1 model requires 108ms on my PC, while compiling the simplified version only requires 356us.

[quagla]

The thing is, visual meshes need to be loaded and compiled for computing inertias. How are you proposing to avoid this?

[JewelryForge]

I apologize for not being clear. By visual-only geom I mean a shape that has neither collision nor mass or density, and is used only for visualization. This is a usual case in my opinion.

[yuvaltassa]

You can try loading with discardvisual and saving. Then loading that model would be very fast.

[JewelryForge]

Thank you for your reply! I'm trying with this

#include <array>
#include <iostream>
#include "mujoco/mujoco.h"

int main(int argc, const char **argv) {
  if (argc != 3) {
    std::cout << " USAGE:  generate_simplified_model <MODEL_PATH> <SAVED_PATH>" << std::endl;
    return 0;
  }

  std::array<char, 1000> error_buf{};
  auto *spec = mj_parseXML(argv[1], nullptr, error_buf.data(), error_buf.size());
  if (spec == nullptr) {
    std::cerr << "mj_parseXML Error: " << error_buf.data() << std::endl;
    return 1;
  }
  spec->discardvisual = 1;

  auto *model = mj_compile(spec, nullptr);
  if (model == nullptr) {
    std::cerr << "mj_compile Error: " << mjs_getError(spec) << std::endl;
    return 1;
  }

  int status = mj_saveLastXML(argv[2], model, error_buf.data(), error_buf.size());
  if (status == 0) {
    std::cerr << "mj_saveLastXML Error: " << error_buf.data() << std::endl;
    return 1;
  }
  return 0;
}

I got an error mj_saveLastXML Error: No XML model loaded. This is because mj_parseXML does not modify the GlobalModel. https://github.com/google-deepmind/mujoco/blob/5ac5cfb618c11ff4aa0199b25c3856da3d194703/src/xml/xml_api.cc#L217-L219 https://github.com/google-deepmind/mujoco/blob/5ac5cfb618c11ff4aa0199b25c3856da3d194703/src/xml/xml_api.cc#L83-L89

As mj_saveLastXML( and mj_freeLastXML) is an interface before the mjSpec interfaces are exposed, now the user can pass an mjSpec* to the two functions, and GlobalModel may not be necessary. Will mujoco consider changing the interface of the two functions, or making them deprecated and creating new interfaces?

[quagla]

Hi, we have mj_saveXML (and mj_saveXMLString) for saving a spec. Could you please try that one? Discardvisual should modify the spec, although I've never tried this use case.

[JewelryForge]

Thank you! I ran some simple tests and found that mj_saveXML does solve the problem. However, the behavior of mj_saveXML, at least the naming, is a bit weird to me. This function is not well documented yet, and I didn't expect thatmj_saveXML needs the model to be first compiled. As mj_saveXML does not require an mjModel as an input, I thought that mj_saveXML is a one-to-one mapping from mjSpec to XML items. For example, I thought after I set spec->discardvisual and ran mj_saveXML, the XML file would have an addition <compiler discardvisual="true" />. I suggest that this function may be further documented or renamed.