Why union of these two do not work?

Replies to This Discussion

Permalink Reply by David Rutten on March 9, 2016 at 3:12am

if you bake them do they union in Rhino?

Permalink Reply by Polux on March 9, 2016 at 5:22am

No

Permalink Reply by David Rutten on March 9, 2016 at 7:52am

Then it's a problem with the Rhino SDK function. It may work better in Rhino6 (it probably does, Rhino6 has much improved solid boolean algorithms), but until then you'll have to find another solution...

Permalink Reply by Polux on March 11, 2016 at 3:11am

Is it possible to download a Rhino 6 test release?

Permalink Reply by Laurent DELRIEU on March 11, 2016 at 4:27am

Yes if you log on discourse Mc Neel with the same email you use for Rhinoceros you will have access to Serengeti discussion and download of rhino 6 and GH 1.0000004

Permalink Reply by Hyungsoo Kim on March 9, 2016 at 3:16am

Or maybe flatten "B" input works?

Attachments:

• SolidUnion.gh, 7 KB

Permalink Reply by Polux on March 9, 2016 at 9:09am

Thanks. It works!
But is there a way to compute it faster? (Without upgrading hardware)

Permalink Reply by Nik Willmore on March 9, 2016 at 1:34pm

I could make it 4X faster with parallel processing in Python if you post a Grasshopper script of it, if I have time this week and you have a 4 core CPU which is fairly standard these days. Otherwise your hardware upgrade would only be incremental to a slightly faster clock speed.

Permalink Reply by Polux on March 10, 2016 at 1:29am

Thanks Nik for your help.

Here is my GH script of my ring.

Attachments:

• BagueUnity4.ghx, 1.3 MB

Permalink Reply by Nik Willmore on March 10, 2016 at 6:31am

Initial confusion was that your gem setting prongs are not made by unioning a cylinder with a sphere but are just revolution of a curve:

That means the indeed slow Boolean union involved is a bunch of objects with the main ring body, and that cannot be done in parallel since you are modifying the item once at a time, algorithmically.

The original example of a cylinder and sphere are textbook failures of the Rhino 5 dumb algorithm, since that combination features kissing surfaces that confuse Rhino about where they are intersecting since really in tolerance values they are overlapping along a ribbon instead of a sharp line.

Normally you would slightly move or rescale one of the pair to create a single loop intersection curve that doesn't wander around in jerky fashion trying to combine two surfaces that fail to actually plunge through one another.

Your main Boolean union is 116 prongs with a ring base, and that's slow because Rhino bogs down as the model gets more an more complicated with each internal step, I imagine.

The speed is not all that slow either, only 21 seconds for the Booleans themselves.

If you turn of Grasshopper preview meshing via the toolbar menu it should be significantly faster while you are tweaking the design.

To troubleshoot the slow Boolean, I went into Rhino and tried merely splitting the ring body with the prongs and that itself was just about as slow as the Boolean union, so Rhino is not being badass about it. Then I exploded the ring body and tried splitting just that with the prongs and it was *much* faster to operate on just that single surface! The black box reveals itself a bit.

In kind, splitting the prongs with that single surface was about the same speed as splitting it with the whole ring body, so no speed gain there.

But, to speed up your script, since we *cannot* in fact use parallel processing, we can instead manually create that prong surface by doing our own splits and using Grasshopper's natural order of parts, hopefully consistent, to get rid of the junk.

That prong surface is item 4 of an exploded object.

So I will mutually split them and tease out the good parts from the junk and then rejoin the parts, no Boolean union component needed.

First, I went into your prong cluster and removed the capping, so I have merely an open revolution surface instead of a polysurface, letting me access the surface trim command after quickly finding the BrepBrep intersection curves between the prongs and the single ring surface.

For that Boolean union step I'm down from 11 seconds to 4 seconds, but confusingly we added a second to the Boolean difference that follows:

It's fast since we are manually selecting junk instead of Rhino having to sort which is which, I imagine.

We still have a slow Boolean subtraction of the gems and holes from the finished ring body.

That's not simple so will remain slow and cannot be parallel processed since again there's a single main ring body being modified in each step, and nor are there simple pairs of split object to select from manually to discard junk.

Attachments:

• BagueUnity4B.ghx, 1.4 MB

Permalink Reply by Nik Willmore on March 10, 2016 at 7:00am

There's an error though, the final object creates an open instead of closed mesh, one with naked edges:

Ah, but that's not my problem, since the NURBS object is closed, just the mesh made from it sucks.

No, something else is different. Only one closed NURBS solid gives a closed mesh. Quite confusing. Both have 616 surfaces.

Did I neglected to FLIP one set of surfaces, so the surfaces are not "normalized?" No, that's not it.

Rhino makes a mesh out of it just fine, no naked edges.

OK this is just a fluke, all I need to do is include the custom mesh settings component:

Now your volume calculation doesn't fail and the mesh has no naked edges.

Permalink Reply by Nik Willmore on March 10, 2016 at 7:10am

Another thing I notice is that your Weaverbird Laplacian smoothing is destroying mesh order, causing self-overlaps:

Actually, that's with the Quality custom mesh component, which oddly enough makes it worse than the default you were using here:

But changing to a slower final mesh custom settings is the key to having control over uniformity:

• ‹ Previous
• 1
• 2
• Next ›
• Page