Clemens Eppner

Thanks! I didn't know that. It looks like these are two versions of quaternion multiplications as described in: https://arxiv.org/abs/1801.07478 , right? I'm open to adding a column to the table.

Just to understand better: The initial report states that `load_mesh` behaves differently but the referenced line above points to the export function. Could you write down an MWE?

I still don't fully understand the problem, the material property is preserved: ``` In [1]: import trimesh In [2]: x = trimesh.load('cube.obj') In [3]: !cat cube.obj mtllib cube.mtl o Cube...

Ok, I get consistent results if I use `GST_INDEP` as the narrow phase collision solver (`request.gjk_solver_type = 1`). Just a wild guess: This might be related to this issue: https://github.com/flexible-collision-library/fcl/issues/243...

Is there any news on this? Is it hard to replicate?

There's a small mistake in the `example.py` when constructing the `fcl.BVHModel`. The arguments of `mesh.beginModel` are swapped. Still, it doesn't make a difference in this particular case. Just to make...

Thanks! Can you point to some specification?