I just finished a pitch that required a massive boolean operation. Imagine a large 2D floral pattern composed of hundreds of parts cut through a plane. I can’t show it because of NDA but I’m sure you can imagine. The pattern was a series of vector shapes (leaves, branches, flowers, etc.) so I was able to convert them all to surfaces. Then I extruded them, made them intersect the wall then started doing a boolean difference. I knew I couldn’t do it in one pass so I did it in groups of 10 -15. I’d run the command, then off to read stuff on CNN while the computer churned away.
The process took a long time. My question - what component of the computer would speed this up? More RAM? Bigger video card? Faster processor?
Unless you’re maxed out on RAM, the answer would be the processor speed (not more cores) and perhaps FASTER memory. The CPU and the memory work together.
But another thing may be a simple script that does a sequential Boolean operation - one object at a time - so you can launch it all at once and then go do something else without worrying if it will fail in between. I have to see if I can dig something up, I may have written something like that in the past…
I’m not entirely sure, but from what I read in your post (extrude a curve, intersect a wall) this seems more like a case of curve projection to a surface. Those operations typically are more lightweight than intersecting two sets of possibly complex surfaces.
Hannes - This pattern is ‘cut out’ through a 10" thick surface so curve
projection might be a part of the process but I’d still have to boolean the
shapes.
Mitch - Such a script would be amazing. I could watch the new Rhino / V-Ray
tutorial on Lynda.com while I was waiting for it to complete. Actually, I’m
a couple of months away from building a new computer and this is the first
time I’ve been faced with a task that might give me some direction as to
which way to go - with the new X99 chip or the slightly older Z97.
Worth pointing out - even on a slightly older computer (i7-2600K with a GTX
570) Rhino was able to complete the process - resulting in a 250mg file.
IF the final surface is a flat plane, THEN I would Boolean all of the curves first. After they finish, then you could extrude the joined curves to the desired height.
By the way, I wrote the Lynda course you mentioned… I compliment your excellent taste in educational materials!
Yes. Of the hundreds of objects needing to intersect there were several that threw up a screen saying ‘non manifold geometry caused boolean operation to fail’ (or some such thing). I had to narrow the selection down repetitively to find those problem objects.
@chuck, is there a way we can isolate the failures in Boolean operations, do you think, and select the objects or something to make troubleshooting easier?
I’m sure we can do better than we are. For Difference and Intersection, we could return the incomplete answer when some pieces fail to subtract or intersect, and also give some way of seeing which parts of the second selection set did not work. This gets complicated when members of the second set intersect each other or intersect multiple members of the first set, but we should be able to figure something out.
The problem here is that normally it’s the base object (from which you are subtracting the others) that has become non-manifold as the result of a partially failed previous subtraction. So at that point, all bets are kinda off… I guess one could check for “non-manifoldness” of the result after every subtraction and then try to undo back to before, then skip the next one… That will be somewhat time consuming, though.
Usually, the non-manifoldness only causes a problem when an intersection curve crosses a non-manifold edge. Currently, we don’t figure out if the failure was really due to a non-manifold input. You get the non-manifold warning if there is a failure and one of the inputs happens to be non-manifold. Given that, the subtraction could carry on even if the base has become non-manifold. I’m not sure how useful that would be. I’ve added the request to the pile. http://mcneel.myjetbrains.com/youtrack/issue/RH-29264
Also, booleans are getting a big overhaul in v6. We’ve been improving the way we handle cases where edges or faces overlap. These are the cases that cause the unexpected non-manifold results.
@jeff_hammond@arail Here is a quickie draft. It will try to jump over failed subtractions and continue. Depending on what you want to happen, the results may be good or not - always check.
In the attached, the normal Rhino command fails because 3 objects have near concurrent surfaces - with the script, all of the single ones plus one of the triplets do get subtracted, leaving two of the triplets.
With a lot of objects the script doesn’t seem to be any slower than the normal Rhino command, in fact it runs slightly faster. In a test here, 625 oval shaped extrusions subtracted from a box, 38 seconds for the Rhino command vs. 31.5 seconds for the script. That’s probably because there’s more safety checking and stuff that goes on behind the scenes with the Rhino command. There will certainly be places where the script might fail though.
nice!
i tried it out on a model i was having these issues with in order to test in different situations but now rhino does the b.difference correctly… so it looks like some tune-ups have been happening… your script works well on it too (1.8secs) and i like how the first selection goes grey when it’s time to pick the subtractor object… (instead of everything being yellow at one point in rhino boolean)
i probably spent nearly an hour doing the boolean & troubleshooting a year or two ago… now it works fine in an eyeblink.
i have another problem model on my other computer (that i think current rhino will fail on)… i’ll try your script out on it in a bit.
on a side note, my script collection is growing… pretty sure you’ve written all but one of these
well, the other file that gave me problems also works now… in the past, it was giving partial intersections of (some) flat solids through revolved surfaces… nothing problematic from my point of view… the command simply failed… but rhino isn’t doing that anymore so that’s nice.
still, i’m happy to have the script now for next time i run into problems…
on a side note regarding the speed… i’m getting slower results on mac with pretty fast hardware (3.5GHz i7 & 24GB 1600 ddr3)…
36 seconds with the script on the ovals and ~45 seconds with _BooleanDifference.
Yes, tried a bunch of stuff that used to make Boolean operations fail and pretty much all now succeed.
My home machine (where the 31.5 seconds came from) has a 3.6 Ghz i7. My work machine is about a year older, also labeled as a 3.6 Ghz, but my experience is it’s slower than my home machine, it only manages 38.8 seconds with the script.
@jeff_hammond@arail Here is a new version with a couple more bells and whistles… Mainly option to delete all, used or none of the objects used to subtract; some more command line reporting, and, for Windows users (sorry Jeff), a status bar progress meter for long operations. Thanks to @Alain and @menno for help on the command line options input.
It should, I specifically set it to detect if it’s running under Windows and if not, I turn off the progress meter so as not to cause any potential problems. In theory, Mac is supposed to ignore the progress meter if it’s it called, but you never know.
