Grasshopper

algorithmic modeling for Rhino

I have a bunch of surfaces that were generated in GH and I want to make a closed Brep out of them with the "Brep Join" component.

GH will not output a closed Brep, but if I bake the surfaces and then join them in Rhino, it works.

I attached the definition and my Rhino tolerance settings.

If I loosen my tolerance settings, (0.1 instead of 0.01 absolute), GH then makes a closed Brep, but I don't want to since I am dealing with such a small object.

Isn't GH supposed to use Rhino's tolerance values to do it's own business ?

Cheers,

Views: 4804

Attachments:

Replies to This Discussion

Maybe David can give you a precise answer, but it looks to me like "that's just the way GH works."  Your end result has 2 naked edges on each of the long sides. If you bake the result and then use Rhino's "Join 2 naked edges" function to carefully select each naked edge you can join them together. The Rhino join command will tell you that it has to use a tolerance of 0.0172909.  Accepting that joins the naked edge pairs and this should give you a 'solid" result.

Here's a Python script that invokes Rhinocommon and accepts tolerance input:

http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Bre...

All I had to do was right click the Python inputs to set a type hint and item or list access. If you zoom way in you see the means to adding and removing inputs:

The Rhino.Geometry and Rhino.Collections namespaces contain most normal Rhino commands.

http://4.rhino3d.com/5/rhinocommon/#

A tolerance of 10,000 works fine, so yeah, Grasshopper is being stingy.

Attachments:

Hi Nik,

Thanks for this.

It can come in handy indeed.

I wonder whether it could invoke CurveBoolean which is something I miss in GH...

Back to my geometry, I think I'd better model my shape in a more reliable way : Network Surface seems to screw with these edges.

Depending on the input dimensions, they are either in the same plane or not, which doesn't make sense given the way the initial curves are generated.

Cheers

In Rhino the CurveBoolean command requires manual selection of inside spaces, akin to a coloring book.

The Rhinocommon command Rhino.Geometry.Curve.CreateBooleanUnion is here and seems happily devoid of user input:

http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Cur...

This is failing to give anything, only an empty list, even if I try the arcane option of tenderly feeding it a formal Rhino CurvesList to begin with.

A forum search ( http://www.grasshopper3d.com/forum/topics/curve-createbooleanunion-... ) reveals the CreatePlanarBreps command, said to work:

http://4.rhino3d.com/5/rhinocommon/?topic=html/Overload_Rhino_Geome...

This works for *some* curves, in a very confusing manner, in that when I feed it all of these curves, I get two surfaces, but it fails when I only feed it the left collection, while the right collection itself works fine?!

I don't get it. Rhino.Curves.CreateBooleanUnion won't work at all on the set or the right or left collections either.

Rhino/Grasshopper is often broken, actually. Same old story. Robust basic functionality goes missing for years.

This C# version of Rhino.Curves.CreateBooleanUnion similarly fails:

http://www.grasshopper3d.com/forum/topics/curveboolean-union-of-cur...

That seems to require only closed curves as input? Ah, indeed, the Rhinocommon entries use the term "loops" which formally must mean *closed* curves, not just open loopy shapes, but then CreatePlanarBreps uses the same term yet does work sporadically.

Here is the CreatePlanarBreps Python script:

The key seems to be to include at least one dummy curve in the system that is self-looping and that changes the algorithm to let the big collection work:

The self-looped curve is required to be included for the big collection to work, whereas merely the lone unlooped curve being included doesn't fix it.

So include a dummy self-looped curve to fix the command and then filter it out later?

Attachments:

Your network surface works for a good join when done manually in Rhino using Loose instead of Position:

Rhinocommon does have Rhino.Geometry.NurbsSurface.CreateNetworkSurface with an auto-sorting version available:

http://4.rhino3d.com/5/rhinocommon/html/Overload_Rhino_Geometry_Nur...

Here is Python for that.

However, I *still* have to use my Python brep joiner since not even Rhino can join this version of a network surface. How very odd.

Settings have little effect on output and I can see the mismatch between the network surface and the flat bottom cap always the same, zoomed in, in wireframe mode so the crude preview mesh is invisible:

Anyway, this Python version will auto-sort your curves, saving much hassle.

Attachments:

The Python script Nik Willmore provided is an excellent solution to this problem. The ability to control tolerance in GH should become standard. 

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service