Open onitake opened 1 week ago
Does https://github.com/mikedh/trimesh/pull/2298 help at all? PR's welcome! One thing that might help breaking this in the future is if we added a test that tried the debian build, which I have no idea how to do but am open to PR's on 😄.
I don't think there should be a Debian-specific test, but rather some better logic to select and test different engines. For example, there is currently no automatic fallback to the blender engine when manifold3d isn't available, or vice-versa. The rationale is that manifold3d is not a mandatory dependency of trimesh, so it shouldn't cause code to fail. Neither is Blender, of course. Boolean operations should only fail if no engine is available.
The unit tests should also run all tests against all engines and fail when an engine isn't available. In the Debian scripts, we can then simply add a small patch that removes manifold3d from the engine list in the test.
I'll try to come up with a PR based on the idea of selecting an engine globally on module load, with the option of changing the detected default later or passing it to each operation (as it's implemented now).
Some of the unit tests have been set up so they execute with all available boolean mesh operation engines, but some of them require the default manifold3d engine.
The Debian build system requires that all dependencies must be available in the Debian ecosystem, but we haven't packaged manifold3d yet and need to run all unit tests against the blender engine for now.
Example error:
Aside from test_multiple_difference, these tests would also need modifications: test_boolean_manifold, test_boolean_manifold, test_reduce_cascade
Maybe it would be a better idea to use a test fixture instead, so all unit tests are always run with all engines? Or perhaps there should be a way to set the engine globally and autodetect available engines on module load.