Coal's assimp dependency issue for Windows

[petercorke]

Background

Coal (our collision backend since v1.2.0) requires assimp as a mandatory CMake dependency. assimp has no Windows wheel on PyPI, so pip install spatialgeometry[collision] currently has no effect on Windows — already documented as a known limitation in CHANGELOG.md, with a conda-forge workaround (conda install -c conda-forge coal-python + pip install spatialgeometry trimesh).

Findings

• spatialgeometry doesn't actually need assimp. Coal's assimp-backed MeshLoader is real, user-facing functionality in Coal generally — but SG never calls it. Mesh._init_coal() (CollisionShape.py:129-147) loads mesh files itself via trimesh and hands Coal raw vertices/triangles through the low-level BVHModelOBBRSS API. So for us, assimp is a mandatory build dependency for a feature we never exercise.
• Coal's own CI doesn't test pip+Windows at all. macos-linux-pip.yml's matrix is ["ubuntu", "macos"] only. Windows support currently exists solely via their pixi/conda workflow, where assimp resolves fine from conda-forge — the gap is specific to pip.
• An unaddressed upstream issue already exists: coal-library/coal#793 "Make assimp optional" (ahoarau, Dec 2025) — zero comments, no linked PRs before ours.
• An in-flight CMake rewrite doesn't fix it: coal-library/coal#794 "Refactor CMake with JRL CMake Modules v2" (also ahoarau) still finds assimp as REQUIRED, just ported to new macros — it's blocked on an external upstream PR (jrl-cmakemodules#798) with no visible timeline.
• CI-time isn't a real objection: checked a recent successful run of Coal's Windows/pixi CI — Windows legs run ~10-34 min, no slower than the macos-15-intel legs in the same workflow (46-48 min, mostly runner-queue time).
• Historical aside: SG's choice of trimesh over Coal's own MeshLoader was inherited, undocumented, from RTB's original PyBullet→Coal migration (roboticstoolbox-python@f99c154f). Coal's MeshLoader was fully callable from Python at the time (exposed in both the old boost-python and current nanobind bindings), so it wasn't a capability gap — best guess is trimesh's broader format support and its use in generating test fixtures (test_collision.py's synthetic mesh creation).

Action taken

Commented on coal-library/coal#793, tagging @ahoarau: explained SG's use case doesn't need assimp at all, offered to implement a small COAL_WITH_ASSIMP-style CMake option, but deferred to their preference on timing given #794's in-flight rewrite. We're not blocked — the conda-forge workaround is already documented — so we're waiting for a reply rather than proceeding unprompted.

Next step

Waiting on @ahoarau's response on #793. If they'd rather we just submit the PR, revisit implementing COAL_WITH_ASSIMP against devel.