Mismatch Between Rhino Model Tolerance and Internalized GH Geometry Tolerance

Greeting Grasshopper Gurus,

I just wanted to put forward a feature request that has caused so much pain in coordinating GH files with the community that I have labeled it as a bug. Whether it is a bug in my own code or in Grasshopper in general is something that I hope to clarify in this discussion.

In the Ladybug+Honeybee community that I frequently develop for, we are often internalizing Geometry in GH files. We have noticed that, whenever this happens, the geometry is internalized at the Rhino model tolerance of the modeler who internalized it. When such an internalized geo GH file is shared with other members of the Ladybug+Honeybee community, this frequently results in a mis-match of internalized GH geometry tolerance and the Rhino model tolerance whoever is opening the shared file.

Many of the components in Ladybug+Honeybee are performing geometric operations with the Rhinocommon SDK and the tolerance is particularly important for these operations. For these operations, we have coded Ladybug+Honeybee to always use the current Rhino model tolerance using scriptcontext.doc.ModelAbsoluteTolerance. As you can imagine, we get a lot of GH files failing because of this mis-match between shared files and I have provided a sample of GH discussions below that have ended in this tolerance madness.

I accept this as a bug in Ladybug+Honeybee if there is some way that I could read the tolerance of all internalized GH geometry instead of the Rhino model absolute tolerance. If someone could show me how to read it, I will replace all tolerance instances of Ladybug+Honeybee with such internalized geometry tolerance (or at least give a warning when there is a mis-match). However, this seemed like it was a bug for the broader GH project as I have noticed that this mis-match causes problems with native GH components. The attached GH file with internalized geometry works if the Rhino model tolerance is set to 0.001 but fails once it is changed to 0.0001.

As such, I wanted to ask if we could at least get a warning message when we open a GH file that tells us when there is a mis-match between internalized geometry and the current Rhino model.

Thanks, as always, and here is that sample of discussions ending in tolerance madness:

http://www.grasshopper3d.com/group/ladybug/forum/topics/radianttemp...

http://www.grasshopper3d.com/group/ladybug/forum/topics/struggled-v...

http://www.grasshopper3d.com/group/ladybug/forum/topics/open-close-...

http://www.grasshopper3d.com/group/ladybug/forum/topics/what-does-i...

Attachments:

InternalizedGeometryError2.gh, 7 KB

Replies to This Discussion

Permalink Reply by David Rutten on July 6, 2015 at 12:00am

(On iPad now, can't open the files).

Document tolerance is used during certain calculations (intersections, trimming, joining) it is not used when serializing Rhino geometry. When you internalise you get the exact data the geometry has. Of course the geometry may suffer from inaccuracies. If you import an object modeled at centimetre accuracy into a millimetre accuracy file, the seams and edges may well 'break', but that's not something that can be fixed, because it requires data which doesn't exist.

Permalink Reply by Chris Mackey on July 6, 2015 at 7:57pm

Thank you for the explanation, David.

I see now that there is no "tolerance property" that is internalized with the geometry, which could allow us to track the conditions under which the geometry was made. The reason that I felt the tolerance was being internalized was just because of the number of accurate decimal places that such geometry had, which affected its performance in subsequent geometric operations. I imagine that, if I wanted to have geometry internalized with such a tolerance property so that a component could at least report a mis-match between the tolerance under which geometry was created/internalized and the current Rhino/GH tolerance, I could set up a user dictionary property for the internalized geometry with RhinoCommon or something similar.

I recognize that I can never fix the problem completely since, as you say, we cannot fabricate data that does not exist. However, a warning to the user to change their tolerance would have solved many issues more quickly and I may try my hand at creating such an "internalizer with tolerance" component unless this is something that was going to be implemented across GH at some point.

Thank you again, David.

-Chris

Permalink Reply by franco ferreiro on March 13, 2017 at 9:42am