This screenshot shows the feature working inside MeshSourcer. A visual mesh with 200,463 faces was reduced to 14,016 faces across 48 convex hulls, a 93% reduction. The color coded overlay makes each generated hull visible, so the collision geometry can be inspected before export.
That workflow became my contribution to URDF Kitchen, an open source set of Python tools for preparing meshes, defining joints, assembling robot parts, and exporting URDF models.
Finding a gap in a useful tool
URDF Kitchen brings several tedious parts of robot description authoring into one visual workflow. MeshSourcer already supported primitive colliders such as boxes, spheres, cylinders, and capsules. Those work well for simple parts, but they can poorly represent grippers, end effectors, feet, and other complex geometry. Using the full visual mesh is expensive, while creating a simplified mesh in another application interrupts the workflow.
I proposed closing that gap in URDF Kitchen issue #6: add a Collision Mesh Generator directly to MeshSourcer using CoACD for approximate convex decomposition.
The process stays inside the application:
- Load the visual mesh.
- Clean it and remove duplicate geometry.
- Generate lightweight convex hulls.
- Preview the hulls in the 3D view.
- Export either one merged collision STL or separate hull files.
From proposal to pull request
The maintainer, Ninagawa123, welcomed the proposal and invited me to submit the implementation. I opened pull request #7 with the integrated UI, mesh cleaning and decomposition pipeline, merged and multi hull exports, preview support, background processing, and 11 unit tests.
After testing it, Ninagawa123 called it an excellent feature, particularly for geometry such as the soles of feet. The pull request was merged into the beta2 branch on July 19, 2026.
Why contributing back matters
I benefit constantly from open source projects whose maintainers make specialized work more approachable. When one of those projects solves most of a problem but exposes a missing piece, I would rather contribute the improvement than leave it isolated in a private fork.
Opening an issue explains the need. A working implementation, tests, and documentation make the idea easier to evaluate. Contributing it upstream means the next person starts with a better tool. I appreciate Ninagawa123 for building URDF Kitchen, being receptive to the proposal, and taking the time to test and merge my contribution.