SDifference stops working in different file

So I've been working on a large file with several custom components when the SDifference didn't work as it should. To see if it worked theoretically I opened a new file and attempted the idea.

What I basically needed was this: the shape that occurs when one substracts a linear column from a cuved column.

Situation 1: SDifference used in a single file

As you can see it works perfectly fine. But now I enter this same element (copy paste), unconnected to the rest in the large file I'm working in and suddenly this is the output:

Situation 2: SDifference used alone in a large file

As you can see, the substract doesn't work as needed any more, even though it is exactly the same set-up. How come this happens and how can I fix this as it is pretty vital for the design.

Edit: I've learned now that it only occurs when the base shape contains curves. It works fine with rectangles/ polygons and polylines.

TL;DR: The Sdifference function stops working when used in a large file.

Attached file: The set-up in the single file.

I am willing to share the larger file as well (109kb), but as it is for school work I don't want to release it this openly. Besides, it shouldn't theoretically affect the problem as it is not connected to the rest right? Anyhow, contact me directly for the large file.

Attachments:

Difference check.gh, 7 KB

Replies to This Discussion

Permalink Reply by David Rutten on June 4, 2016 at 9:06am

Lots of components inherit their tolerance settings from the 3dm file which is currently active. Are your two files 'running against' different 3dm files?

Permalink Reply by Wouter Roos on June 4, 2016 at 12:39pm

If by 3dm file you mean the file that Rhino has open, then no. It occurs when only changing the grasshopper file.

Permalink Reply by Wouter Roos on June 4, 2016 at 1:01pm

Ok, I did some experimenting and I discovered the following. It is the combination of a curved base along with a curved extrusion that creates the error. So when a circle is extruded along a linear line it has no problem, however, when it follows a curved shape it does. To make it even more complicated, I had two planar 3 pointed curves, on one it worked, and on one it didn't. not even in the file I send.

Permalink Reply by David Rutten on June 4, 2016 at 1:08pm

Solid operations that involve coincident or tangent edges have always been problematic for Rhino. It's better in Rhino6 (I assume you're running Rhino5?) but it's still not flawless*.

If you bake the geometry and perform the BooleanDifference in Rhino itself, does it work any better?

* In fact this week there was a heads-up from the surface intersector math guys saying they improved the overlap cases and to be on the lookout for potential breakages.

Permalink Reply by Wouter Roos on June 6, 2016 at 12:04pm

Sorry for the late reply, and thank you so much for helping!

To answer your questions, yes I indeed use Rhino 5 and unfortunately no, BooleanDifference in Rhino doesn't work either. For now I'll write down this to hardware limitations somehow, along with a limitation that the tool doesn't work in all cases. The scope of my project was pretty broad anyway, so having some constraints (albeit unvoluntarily) might not be a problem.

Again, thanks for the help. If you happen to know something that could enlighten me more, I'm happy to hear something of you (as I'm still pretty new in the Grasshopper circuit).

Permalink Reply by David Rutten on June 6, 2016 at 3:11pm

For now I'll write down this to hardware limitations somehow [...]

Oh it's certainly a software problem. The algorithm we use in Rhino to solve this case gets confused and gives up. Grasshopper relies on Rhino for almost all its geometric algorithms, so if it's broken in Rhino it'll be broken in GH as well.

I suppose we'll have to test it in Rhino6 to see if it's any better, and if it still fails then a formal bug report can be made with the Seattle maths experts.

RSS