Looking at the Grasshopper implementation of the Speckle plugin, I think there might be some incorrect assumptions - Grasshopper does, in fact, use double precision meshes - you can check the flag UseDoublePrecisionVertices:
In some cases, like with Brep conversions close to zero, a mesh will be created without double precision enabled, but when you transform it to the point it needs it, it will become enabled:
This may have been an oversight on our end on attempting to fix jagged meshes that were very far away from the origin.
Rhino and Grasshopper are sharing mesh converters, so if this is a problem in GH it may also apply to Rhino - I’ll open a ticket to see if the api method you identified fixes all of the edge cases we’ve observed
The use case in this example is civil objects being sent to c3d (which will always be far away from origin), so just a reminder there that meshes aren’t just for preview
As a short term workaround. You may find some precision improvement by adding your objects a rhino Block. As it will store the transform and mesh vertex data separately (however, still as single precision floats)
I’ve got a pr open to revert to using ToPoint3dArray() , which we were doing in v2 but (maybe too enthusiastically) optimized for v3 to improve conversion performance. So the fix is there already, but we have to do some testing on large models first and see if there’s a way to maintain current perf (esp in rhino) without losing precision for far away meshes
