google-deepmind / google-deepmind/mujoco
Allow mesh for sole visualization purpose
- 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
Assessment
This issue has not been assessed yet.