Is there a fix for this?

I have a group of conjoined boxes that looks like this:


I removed the bottom surfaces of all the boxes to make an open shell like this:

My intent is to put a light inside so it can show out through holes (windows) in the outside shell. To test this I made a rectangular solid cutter that makes a window on opposite sides:

So I made a big collection of cutters like this:

Then I did an SDiff and got this:

Not bad for a first try - but the bottom looks like this:

Oops! It looks like SDiff returned the original bottom surface before it did the subtraction. My guess is thatā€™s because it uses the original Closed Brep version of the shell, even though itā€™s input was not that. The bottom surface makes it impossible to put a light inside the shell, so Iā€™m stuck,

I thought maybe meshing would be a solution, so I made this to test that idea:


This fails by ultimately crashing my PC with an out of memory error. I have attached the GH file for anyone who wants to mess with this - note that the SDiff is disabled. This allows you to load the file and see the shell and cutters, but enabling the SDiff take about 3.5 minutes to compute on my system, and a bit more to display the results. I left the mesh components in there but I wouldnā€™t try to use the MDiff.
bb-test1.gh (2.7 MB)

Time: 3 minutes.

1 Like

Alignment of your ā€˜Cuttersā€™ with your ā€˜Shellā€™ is poor. Why use SDiff when your ā€˜Shellā€™ is an ā€œOpen Brepā€ :question: (not ā€œsolidā€)

But SDiff appears to work if you separate the X and Y cutters and do them one after the other. Still, I can think of multiple ways to do thisā€¦

Leopold: thatā€™s close, but still not quite right. There are lots of missing parts/walls.

Joseph: Aha! Thanks. Iā€™ll try the one group of cutters at a time. (But I wonder why this will work differently from the 2 combined.)

Iā€™ll do some experiments with Trim also - not tried that one before.

23.3 minutes. Utterly ridiculous :bangbang: You are far from new at this @Birk_Binnard, so you should know better.

The GH file is 3.1 MB so I wonā€™t bother to post it.

P.S. Still ridiculous but better - 12.3 minutes.

Time: 20 seconds.
But itā€™s not perfect.
bbtest b.gh (194.0 KB)

1 Like

Very nice :bangbang: Looks very close to perfect to me. Well done. :+1:

That looks good to me - certainly better than anything Iā€™ve been able to come up with using SDiff or Trim. (I need to understand what the difference is between those 2.) The problem I have with your method is it is so unintuitive - at least for me. Itā€™s going to take me a while to figure out why it works as well as it does.

My method basically involves cutting out individual faces rather than the entire brep.
I slightly modified the surfaces to get a better result.
bbtest c.gh (125.0 KB)

Thanks for your continued interest - your GH file is a very helpful learning tool for me, and I am (slowly) starting to see how your approach to this idea works. To that end Iā€™ve re-formatted your solution to look like this:


Your method uses a number of GH components Iā€™m totally unaware of, so itā€™s going to take me some time to learn about them. Iā€™m guessing this is because you know how to use Rhino - and I do not. All my work has been with GH only; my only use of Rhino is as a display medium.
I see you did some separate work to separate the column tops from their sides. Thatā€™s something I knew I would have to do eventually since there is no way to 3D print the tops without underlying supports. I donā€™t do supports, so my solution for this is to extrude the tops to a peak as shown he this screen grab:

My real GH file is built with a boatload of sliders that control all the geometry objects, and Iā€™m (slowly) experimenting with how to tweak different sliders to enable all the cutouts to appear in the proper places, while at the same time being a reasonable size. Iā€™m currently working on ways to gab all the top surfaces rather than just pick one. Iā€™m not sure yet how Iā€™ll deal with the issue of overlapped/truncated tops.

====================================================================
OK, Iā€™m Iā€™m not afraid to admit that your method is far superior to mine, and more importantly, that mine will probably never work the way I intended.

I generated the boxes from a set of random sizes because I thought I could configure the size and placement of the cutouts to fit simply by tweaking their parameters. After trying that for a while Iā€™m thinking that is just not going to work, basically because there is no ā€œone size fits allā€ set of cutout parameters that will work.

Your solution completely solves this problem, including the one about extruding the tops:

Using your method this was surprisingly easy to do:


So it looks like Iā€™ll be working with the individual boxes like you did. Thanks again for saving me from myself. :grinning:

1 Like