search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.35k stars 1.27k forks source link

[MuJoCo Parser] Support for applying texture (for example from images) directly to primitive geometries #21958

Open agarwal-abhinav opened 1 month ago

agarwal-abhinav commented 1 month ago

Is your feature request related to a problem? Please describe. Currently, the MuJoCo parser doesn't support applying texture directly to primitives. For instance, if a geometry is specified by primitives in the .xml file, and a texture is added to it via (say) a .png specified in the .xml, drake doesn't currently support loading that. This requires reasoning about converting the primitives to .obj, the texture mapping to .mtl, and then modifying the .xml to load the .obj. This is tedious pre-processing and doing it without human in the loop requires reasoning about u-v coordinate maps in a generic way, which isn't always convenient given multiple options for mapping texture in the .xml.

Describe the solution you'd like Currently, drake supports adding texture directly to primitive geometry in .sdf files for visualization in camera rendering.

  1. First suggestion is to add the same feature for parsing mujoco .xml.
  2. Second suggestion is to add the feature to visualize it meshcat as well. Doing this will not only allow rendering of the scene from camera, but also visualization of the robot trajectories.

Describe alternatives you've considered Even if the mapping to .obj works well for visualization in meshcat, it doesn't always work well in camera rendering (or vice-versa). Attached is an image as an example. Additionally, the right wall in the meshcat rendering can make it clear that getting u-v coordinates right isn't the most effortless pre-processing.

Additional context There is some elementary discussion about this on the drake developers slack. cc @SeanCurtis-TRI The attached example is part of an effort to load robocasa environments in drake for combining learning based robotics (needing a large library of feature rich yet varied environments) with model based tools like GCS. cc @GenericP3rson who has been working on this and provided the attached visualization. This issue is closely related to the work being done in #20444 cc @RussTedrake

IMG_8151

SeanCurtis-TRI commented 1 month ago

This is related to #19076. When extracting material definitions from the mjcf file, they'll inevitably end up in GeometryProperties. However, those don't make it to Meshcat (as per the linked issue). So, the solution for this issue requires resolution of both issues.

RussTedrake commented 1 month ago

My understanding is that now that we have "in memory mesh files" support, a new potential solution to this problem is available, at least for the simple case (e.g. the anymal-c model, which is the first model missing textures called out in #20444): 1) the assets are already in obj 2) the texture elements in the mujoco xml just point to the respective pngs.

In this case, I think, we can just load the obj as an in-memory mesh file and add a trivial .mtl file + the .png to get things working. Note that the mujoco menagerie obj files (and many other mujoco files I've seen) actually include a reference to the .mtl file in the obj, but don't actually distribute that .mtl file -- it's simply missing. :see_no_evil:

FWIW - Here is the initial PR I had which implemented a lot of the texture parsing in the mujoco parser, but we decided it wasn't ready to land at that time due to the lack of support in Meshcat.