google-deepmind / google-deepmind/mujoco

Allow mesh for sole visualization purpose

Open
#2,455 4 comments 2 reactions 0 assignees View on GitHub
enhancement
Dominant language
C++
Stars
15.2k
Forks
1.8k
Avg merge
10d 16h
Merged PRs (30d)
25

Description

### The feature, motivation and pitch

For some context, I don't think MuJoCo supports `material_index` mechanism to associate different faces of a mesh to multiple materials (colors) as some more dedicated renderers do. Two workarounds are:
1. UV unwrap the whole mesh, assign different colors to different parts of the texture;
2. Split the mesh into multiple sub-meshes, then one material each sub-mesh.

I go for the second approach, then encounter several strange bugs related to planar mesh (in <= 3.2.7). In 3.2.8, setting `inertia="shell"` resolves this issue. But even in upcoming 3.2.8, all meshes are forced to compute inertia, re-centering, and compute BVH, which is wasteful for sole visualization purpose. So, I hope MuJoCo could implement a flag to skip such process for certain meshes.

As a generalization, currently MuJoCo supports `mjr_uploadMesh` to update mesh dynamically for visualization. But it only takes the `meshid`-th mesh from the associated `mjModel`. Since MuJoCo stores meshes in a memory-efficient flat format, adding new meshes or adding / removing vertices from a mesh is very difficult. I think, mesh for sole visualization purpose could safely skip the whole MuJoCo core engine, and be supplied directly to the render context or visual struct.

### Alternatives

_No response_

### Additional context

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.