There seems to be a bug in Rhino 7 that causes problems when using the command “Intersect”. It’s been doing this since I upgraded at the beginning of the year. I thought it was my models and it’s caused me a lot of grief. I kept thinking that I don’t remember that ever being a problem. I finally realized that the problem was with the current version, because I am able to take the model I’m having a problem with and throw it in Rhino 6 with no problem whatsoever. I just wanted to make someone aware. For now, I’ll just work in 6 until this is fixed.
Intersection Problem.3dm (223.2 KB)
Hello - the document tolerance is 0.000001mm - that is really on the low side of Rhino’s happiness range - .001 or .0001 should be plenty for most purposes and will allow the intersections to work as expected.
-Pascal
I would prefer that, though both Smart 3D and Femap require that tolerance for objects imported to them. Is this the answer then? Rhino 7 is less tolerable than Rhino 6?
Yes, I see that V6 manages at this tolerance - I’ll see what the developer says, thanks.
@michaelmartinez those apps really require .000001 mm??
-Pascal
@pascal, yes, Smart 3D requires 0.000001 (mm specifically) or less between surfaces and femap requires 0.000001 of any unit you are using. I’m not sure if I can pull some tricks (scaling and whatnot) for femap, but yes, Smart 3D is very strict.
Edit: Perhaps I am mistaken. This was years ago. Maybe it was changed or I misremember. I’m finding conflicting information when doing research now.
Does anybody know if there is any kind of internal difference within the model definition or software when, for example, 0.000001 m would be used as opposed to 0.001 mm?
It’s just that as far as Rhino goes, as I understand it, it is happier with not too extreme numbers - .01 >.000001 is what I recall hearing from the developers is best - you are at the small end of the range, and should be ok - there is clearly a bug in your example.
RH-70545 csx: curve surface intersection failures example
If I had a choice I’d opt for the middle - i.e. mm in your example.
-Pascal
Your curves are 40m in length and you require 10^-6 mm of accuracy in the results. That is 11 digits of accuracy you expect in your results. Double precision floating point numbers only record 16 significant digits.
This is a low priority problem. There are many examples of curve-x-surface intersection failures that are more reasonable than this.
Perhaps it’s clear I don’t understand the underlying issue. Your comment does nothing to further my comprehension of the subject in question. I would like to learn, sir, not just complain that something isn’t working how I want it to.
Also, why are there “many examples of…failures”? Is each one specific? Is there a pattern?
Thanks.
According to the doc posted above it’s 10^-6 meters, not mm… So 0.001mm. Still, demanding that accuracy over 40 meters remains nothing short of ridiculous. Nothing in our normal physical world can be built that accurately.
The model that was sent in has units set to mm and absolute tolerance set to .000001.
If the user is trying to achieve a tolerance of .000001 m (which is physically unrealistic for a object of this size, but I think it is reasonable as a numeric computation problem). The tolerance should be set to .001.
Michael,
Mitch has spotted the error. The doc you posted from Smart3d specifies a tolerance of .000001m. Since your model is in mm your tolerance should be set like this:
I think the problem was that V6 is OK with the numbers as is, and V7 not.
-Pascal