Problem with Soild Difference

Replies to This Discussion

Permalink Reply by Bas Goris on March 10, 2016 at 2:48pm

Hi,

Maybe related to the problem above: when I delete some of the curves curves in rhino, the surface from the loft function appears fine, but the Solid Difference does not. Seems a bug to me. Can anybody help?

The problem appears when I delete the curve number 13 or 11 or 5 or 4 or 0.

See attached grasshopper file with the related rhino file.

thanks,

Bas

Rhinocentre.nl

Attachments:

• ProblemWithSolidDifference_2.gh, 23 KB
• LooseLoftCurves_ContainerVessel.3dm, 39 KB

Permalink Reply by Pieter Segeren on March 10, 2016 at 2:57pm

Admitting I first thought the SolidDifference was the wrong tool (surface isn't a solid) I created an 'old fashioned' method using SurfaceSplit.
Then it turned out you cAn use the SolidDifference for this purpose too, but only if your surface complies to some U-V and normals directions rules it seems.  
If you flip your profile curves and reverse their order before lofting them, it'll work.

Attachments:

• ChallengeWithSolidDifference_PSG.gh, 52 KB

Permalink Reply by Bas Goris on March 11, 2016 at 3:37am

Hi Pieter,

Thanks a lot!

Although this seems as a trick to me. Strange that your old "fashioned way"  is working (creating the deck and the aft surface by SurfaceSplit of the bounding box and joining them into one solid).

By the reversed order of the Loft Curves, the SolidDifference is still not working when I trim the surface by a box1 which is scaled over the z axis. But it does work around the problem of the deleting curve number 13 or 11 or 5 or 4 or 0. Strange, strange strange..... Maybe something for David?

Is there an explanation why the reversed order of the lofting curves is working better?

Cheers,

Bas

Permalink Reply by Pieter Segeren on March 11, 2016 at 6:44am

It's a bit of a trick indeed, I agree. That's why I reverted to the proven old fashionend approach. Reversing the profile order reverses the surface's u direction (and thereby the normals too).

B.t.w. there's something funky happening in the bow section that seams to cause the intersection to fail (I've marked it in the definition so you can check). Isn't there a cleaner way to create the hull shape? This is the culprit every time I think... not so much the boolean component(s).

I ended up cheating: move all curves a tiny bit in Y dir...

Attachments:

• OddLoftCausingChallenges_PSG.gh, 40 KB

Permalink Reply by Bas Goris on March 15, 2016 at 4:03pm

Hi Pieter,

Thanks for the effort. Even the cheating: move all curves a tiny bit in Y dir... is tricky. 

Is there another way to tackle/cheat this problem? Is there something like a "pick valid solid function"? See attached.

Cheers Bas

Attachments:

• OddLoftCausingChallenges_PSG_BG.gh, 35 KB
• PickValidSolidFunction.gh, 62 KB

Permalink Reply by Pieter Segeren on March 16, 2016 at 2:42am

Hi Bas, adjusting the document tolerance could help (preventing need for that tiny cheat), but I'd say that's equally - as you call it - "tricky".
You could sort the parts by (center point maybe) Z value to select only the correct part.

Permalink Reply by Fred Becquelin on March 11, 2016 at 7:29am

Hi,

Personally I quit trying to use solid boolean ops for hydrostatics. I always explode the Brep and trim each faces with the waterline.

Point of interest : volume calculations are much much faster on meshes than breps... However the mesh for a closed brep isn't always watertight.

Permalink Reply by Bas Goris on March 15, 2016 at 4:08pm

Hi Fred,

Thanks for the suggestion of using a mesh. That speeds up the calculation. I also use toggles to switch of parts of the calculation.

I hope that the Grasshopper team can improve the solid boolean functions. Thats why I am posting this too.

I have looked at your stuff on the grasshopper newsgroup. Nice stuff for the marine industry.

cheers,

Bas 

Permalink Reply by Bas Goris on March 29, 2016 at 10:07am

Hi,

I think the title of this topic should be changed into " Problems with Lofted Surface".

All simulair manual functions in Rhino are fine, but bugs appear in Grasshopper. I hope someone can help. I would like to get a trick free grasshopper script, because about 120 students needs you use it.

See attached rhino and grasshopper file.

I have made loft curves in Rhino and a lofted surface is made in Grasshopper. The uppermost control point of curve 12 is set above the uppermost points of the other curves:

I have made a box in grasshopper to split the surface:

The Brep Split in Grasshopper does not work. It should result in three trimmed surfaces instead of two:

When the uppermost control point of curve 12 is set below the uppermost points of the other curves the split function workes fine again. The split in Rhino workes fine when I bake the Surface and the box in Rhino.

Cheers,

Bas

Attachments:

• LooseLoftCurves.3dm, 49 KB
• Brep Split Bug.gh, 36 KB

Permalink Reply by Pieter Segeren on March 29, 2016 at 3:22pm

The only thing I can think of to fix this, without interrupting your workflow, is to extend the surface so it will intersect nicely with the trimming box. I couldn't resist to use a nano-cheat in the attached definition, but I've put the ExtendSurface in there too.

Attachments:

• intersectionfail.png, 50 KB
• BrepSplitBug_Extend_PSG.gh, 37 KB

Permalink Reply by Bas Goris on March 30, 2016 at 1:34am

Thank you Pieter,

I think I use the nano cheat this time.

friendly greetings,

Bas