Is this another SDiff quirk?

Here is my base geometry:

I want to create grooves on the outside using these ribs:

Joining the ribs to the base yields this:

But using SDiff yields this:

Not only are some of the subtractions not there, the missing ones change depending on the number of horizontal rows and/or vertical columns specified by the # Rows and # Cols sliders.

I’m hoping this is the result of some mistake I’ve made - but is it? Or is it just another one of life’s mysteries?

The attached GH file has most of the required geometry internalized. Be aware that the final SDiff takes several minutes to complete. So you might want to start off with the solver locked. (34.8 KB)

Pipes that touch tangently are always going to be a problem in Rhino, as it will result in tiny differences due to tolerance. If you can live with it, I’d make the horizontal pipes 0.01 bigger. I used my own sdiff ‘component’ which calculates a lot faster: (34.0 KB)

My gosh - what a spectacular solution. Thanks. Needless to say I never would have thought of anything like this. It does, of course, raise all sorts of new questions (none of which you need to bother with):

  1. Why does this work? In other words, why does a 0.01 difference in just one of the radius values enable the solution to be calculated correctly?
  2. In my case (3D printing) a 0.01 difference is totally insignificant. But for other uses the difference might need to be 0.0001 or something like that. Will that also work? How would one determine what an appropriate value would be?
  3. Why doesn’t GH use this method itself? (It’s just 3 lines of code!) ANd yes, it really is a LOT faster. :grinning:
  4. How many other GH quirks are there that could be solved with similar methods?
  5. How did you discover this method? Or even suspect what the problem might be?

It works because it avoids unambiguous intersections.

In general it is recommended that any feature you draw in Rhino is at least 10x absolute modeling tolerance, hence I chose 0.01

I’ve asked this question already but so far haven’t gotten a response other than that it will be looked into.

I can’t tell but there are a couple of gh native components that were either slow or gave unexpected results that made me investigate different solutions. Not many though.

Like mentioned two pipes that are of same diameter and cross like this are a good recipe for unambiguous intersections to occur. I was actually more surprised to find that it did a good job for the most part.
As for my own solid difference code used, it is faster as it is trying to do all in one go, and it will fail completely on your original pipes, I think the native code is trying to do one by one but I’m not 100% sure about that.

Fascinating - thanks again.

Wow - I used your Sdiff replacement on a fairly complex part and the compute time went from 2 minutes down to 12.6 seconds. Pretty amazing stuff - congrats again. I’ll be using your method from now on.

Could a similar method be used for the SInt function? I’d write the code myself but I have no idea what the name of the Rhino SInt function is - or how to find it.

1 Like

Oh goody! Now I get to write my very first Python script! (Finally I’ll have something to impress my grandson.)

Wow - unexpected result! Using the same geometry in the same GH file the standard SDIFF takes 28.4 seconds, but the CreateBooleanIntersection method takes 1.2 minutes. So clearly the Rhino CreateBooleanDifference routine uses a much different method for doing it’s work.

If only we knew what it was…

Can be many things. First of all you are comparing solid difference with solid intersection. Furthermore there are ways to speed things up depending on your geometry. But no matter what you do booleans will always be slow. My first approach is always to look for other ways to model than with booleans.