there is a bug - rhino does not find the intersection of these two surfaces:
_intersect not working correct.
the workarround:
is to extend the common edge / the edge that both surfaces share.
_extendSrf
Intersect_bug.3dm (56.9 KB)
1 Like
Hi Tom, I see that, thanks; for now, temporarily insert a bunch of knots into the smaller surface, Intersect, CopyToClipboard, Undo, Undo all the knot insertion, Paste.
(InsertKnot > Direction=Both > Automatic - repeat maybe 4-5 times to get the surface nice and dense)
http://mcneel.myjetbrains.com/youtrack/issue/RH-34148
-Pascal
1 Like
Likely because the fix is not as straightforward as you appear to think it is and the developer has a lot on his plate?
-wim
“7 years later”
and sorry - i don t think it s easy, but i think it is important, as this is some very basic geometric function it might also cause other failures for example for fillets - that s why I pointed topic to this again after 7 years.
kind regards - tom
2 Likes
this is why I think it is important - or even linked…
all is quite basic geometric stuff…
and @wim the original release Target for RH-34148 was 7.0
now it is 8.x
2 Likes
Hi Tom -
Developers often go through their list and reschedule items.
Please note that RH-34148 is very specific to that one file that you sent 7 years ago. The code in its current stage is the result of 25 years of careful fine-tuning. Modifying this code to make that one specific case work will not necessarily make any other case work. So, unless you are revisiting that exact same file that you sent in 7 years ago, you should post a 3dm file with a different case that is not working. Perhaps the case that you are looking at today is a lot more easy to fix but we won’t know that until that specific condition is checked by the developer.
-wim
I still see various scenarios where intersection between two surfaces fail. Does that mean that if I report some bugs like that, the “McNeel” team will fix them for Rhino 7? 
I’m not sure what you mean.
V7 is still the production build (no date announced for 8 yet) and they have continued to make fixes and updates.
Last year several staff members of “McNeel” noted that only critical bugs will be fixed on Rhino 7 from that moment on, while the remaining “non-critical bugs” (not related to performance and program crashes) will be left unresolved and hopefully see future fixes in Rhino 8. I used to report various bugs multiple times over the past few years, and unfortunately the majority of them were not resolved and will probably forever stay active in Rhino 7.
1 Like
All I can say is, check the release notes.
Obviously, there’s some math they do involving priority, difficulty, and time to V8 release, but they’ve continued to patch things even recently to say nothing of since that year-back date you mentioned.
Unlikely. The only fixes that will possibly be made to V7 at this point will be crash bugs or something similarly critical…
Yes, very obvious intersections fail unexpectedly from time to time.
It has been getting better over the years from version to version, but it still occurs.
Sometimes, not always though, cranking up tolerances can be of help.
For a nurbs modeler, I believe it is unacceptable to drag unresolved functional bugs from version to version. Even worse, when they were reported, placed on a bug list, and neglected for several years. Nobody demands absolute perfection, which cannot exist in software, but giving priority, yes! Even several special cases of Shell, Offset srf, etc., have been postponed until version 9 (many of which will almost certainly be fixed in Rhino 10, and so on). A CAD that works well in at least 90% of cases, robust, reliable in its basic operations, is worth more than a thousand new tools and commands (often functioning approximately).
1 Like
It was discussed many times over the years that a good solution would be to increase the density of the isocurves under-the-hood to make the calculations more precisely, then show the resulting intersections on the original surfaces. This should be automatic and not something that the user is forced to do manually every time to avoid that particular bug.
That seems like an unreasonably high bar given that bug reports are not a static situation. Sometimes it would even block the release of fixes to other functional bugs: that’s certainly the case with V8 in which a significant rewrite either automatically solved or enabled solving things that were simply not practical to fix in V7.
I believe any argument with that statement would amount to version naming rather than actual development practices. “So release the new one as 7.38 instead of 8.0 because it doesn’t clear the functional bug list even though it’s a dramatic change internally and visually” is just a question of what color you paint the box it comes in, not how you develop the product or how it behaves for users on the latest patch version.
I do agree that devs should generally focus on maintaining a solid foundation before getting distracted by a new shiny thing.
1 Like
EDIT: this intersection is solved - no further action needed.
See @Gijs post below
The Problem is a much to accurate unit tolerance
originial post
intersection still fails for some very simple cases in V8 (and V7)
(surfaces are 5 digits away from origin, but this should not be a problem - problem is not gone if moved to 0,0,0)
CantIntersect.3dm (50.4 KB)
EDIT: deleted my bad feeling’s statement
kind regards - tom
intersects here in 8.4.24023.15002, which version are you running?