Grasshopper

algorithmic modeling for Rhino

Hi Guys

I was quite exploring grasshopper and it is not bad.
Intuitive to use.

I was curious about the following commands:
- blend surface
- curve network
- fillet

Might those or could those be implemented at one point?

We would consider using GH in Rhino to simulate parametric
modeling approaches.

Views: 9156

Replies to This Discussion

Alas, unlike the Rhino command, there is no option for automatic or natural alignment, just control over domain start and end of each brep edge which might give that option if I could calculate it, though I'm not sure how to actually change it since I'm stuck with fixed start and end points essentially, and can't jump the gap. Rhino is on the left.

If I add a fixed number (2) to the start end end interval domain values, it just breaks since I assume the second number is outside the actual domain, so no, Rhino won't just cycle around to jump the start/end point.

If I simply reduce the end point of the each interval, it does work to give a gap though, so interval is working, but no, I don't see a way to use it to control alignment of the blend.

I may have to rebuild the the UV direction of the small surface itself, if possible. No, that's not possible, but there is ability to change a brep edge closed curve seam:

http://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_...

Attachments:

Nope, changing the seam location does not change the blend surface twist, no matter what +/- number I try:

BrepEdgeB.ChangeClosedCurveSeam(-10)

But in fact, nor does this alter the edge curve domain since any value of seam change does not change the test point location at position 0:

BrepEdgeB.ChangeClosedCurveSeam(-10)
POINT = BrepEdgeB.PointAt(0)

It seems the domain is updating, or just nothing is happening, or the blend command relies on UV direction, not edge curve start/end point.

The question of getting blend to work at all is mirrored here:

http://discourse.mcneel.com/t/scripting-blendsrf/24635/4

Clearer view of the dilemma:

Though I can manually adjust the closed surface seam in Rhino that the little dome is derived from, and affect the twist, this isn't applicable to an open trimmed surface made via patch:

Like ChangeClosedCurveSeam, SetStartPoint has no effect:

POINT = BrepEdgeB.PointAt(10)
BrepEdgeB.SetStartPoint(POINT)

http://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_...

Attachments:

Both ChangeClosedCurveSeam and SetEndPoint return a False value when printed so I guess they don't even apply to brep edges, even though they do appear in the BrepEdge methods listing.

http://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_...

The loft command in Rhino is similar to blend surface in allowing you to specify a start point of each curve, and that is reflected in the Rhinocommon command that it uses:

However, the blend surface command in Rhino actually only allows Natural vs. Automatic, not in fact fine adjustment of start points.

It looks like the Rhino 6 Rhinocommmon blend command is sadly inadequate for practical use since you cannot specify start points for each edge.

With some help from Clement on the Rhino forum ( http://discourse.mcneel.com/t/scripting-blendsrf/24635/9?u=nikwillmore ) and a very long nap I have a kludge to re-align one of the surface edge starting points to achieve auto alignment of a blend independent of item rotation.

The trick is to re-trim the underlying surface, treated as a Rhinocommon BrepFace, using a curve whose start point is moved to be as close as can be to the start point of the main body edge curve. Using BrepFace split means I didn't have to recreate a brep the hard way, old school. I'm shocked Rhinocommon lacks a simple brep split command using curves.

There is still flipping of *direction* though to consider, which the blend command can change, and which an automatic solution may be too arbitrary for some near ninety degree angles where the little cone is desired to assert itself in either concave or convex fashion.

Attachments:

Fantastic. I only have one more glitch but I would rather avoid Rhino 6 WIP since no wealthy clients will have it or want to deal with it unless there's no other option. Alien technology, no matter how magic, doesn't go over well with bureaucratic firms.

Thanks for the custom tutorial, as I was struggling to get a result. Your blend component won't recognize the circular ends of an exploded cylinder, nor my split/rescaled sphere parts.

My initial concern is if the separate blends of quadrant-split objects will match up with less perfectly symmetrical shapes.

It works! I can join the four resulting blend surfaces just fine. Even if I point edit one of the naked edges it doesn't break the continuity. That's wild.

However, I cannot break a large parent surface with holes into little pieces, rationally, if the holes are rather randomly placed, so this extra work is discouraging. I have to strategize splitting things to feed a black box.

It's always fun to see a new plug-in that has no icons yet. There's so much mesh work now in Grasshopper, but the solid modelers who manufacture products still freak out about meshes, so with even basic Rhino commands being lacking in Grasshopper, no wonder it's still mainly architects rather than industrial designers who adopt Grasshopper.

Having solved the flipping problem so they auto-align in edge direction to not create a mess, I now discover a new glitch in that depending on the angle of the little guy and its re-trimming curve, I'm getting not one brep face edge curve but often three, so I get a gap in my blend surface:


There doesn't seem to be a merge command in Rhinocommon equivalent to Rhino MergeEdge. Maybe I in fact do have to build a brep from scratch, old school?

Attachments:

The same silly gap occurs when I try using node-in-code to access the native Grasshopper Surface Split component, also oddly depending merely on the angle of the little dome in space, only working when not angled in fact:

import ghpythonlib.components as ghcomp

...

AutoAlignedChild = ghcomp.SurfaceSplit(ChildBreps.Surfaces[0].ToBrep(), TrimCurve)[1]

That's just goofy, but it's internal black box stuff doing its thing so I indeed have to learn to build a brep from scratch, hoping that will not do the same damn thing of including three instead of the obvious one edge curve for the boundary, called BrepEdges in Rhinocommon. You can see these by using Rhino show edges, at least:

The Grasshopper Deconstruct Brep component can also see the extra edge vertex:

Again this is taking an existing dome, untrimming it after extracting its trim curve, then re-trimming after editing the start point of the trim curve, so to affect the outcome of the Rhinocommon surface blend command only available in Rhino 6 WIP.

The only place to learn to build a brep from scratch is evidently here:

http://discourse.mcneel.com/t/building-a-brep-in-rhinocommon/11484

However, that's for a flat surface and Rhinocommon only allows 2d trim curves to be added?! So there's no info on how to trim a surface to make a brep if that surface is not flat.

I don't see your components in the Python node-in-code suggestion menu:

All I see is:

Ah, there they are, in a sub-category called AST_GH:

Don't worry, I don't know *how* to make a component and don't *want* to know how :-).

In node-in-code Python, a hack they added, we can access any Grasshopper component, alas no right-click component options only the default, as long as we know the name of it or can find it in the suggestion menu. It's just another way to use your normal plug-in.

Your component, I did find, I just hadn't ever seen submenus before in the suggestion menu, so that threw me off at first.

Your Real Trim doesn't work for my circle and a sphere:

It seems to want a brep input, so it converts my circle to a surface, but in the general case of a 3D trimming curve, it won't be able to create a brep, even, I assume. I get the same result using node-in-code call to the same component.

I just dawned on me that probably I can solve my weird brep edge problem by just stop using spheres that contain their own seam line which is what seems to be giving the extra edge curve and its extra vertex, when they don't line up with the end of the trim curve. This exercise is making me a lot more aware of what a brep really is. My new problem sudden appeared when I forgot to internalize a surface and quickly made a new split sphere that has a damn seam in it. No wonder Rhinocommon is giving two edges instead of one to create the trim curve!

McNeel should hire you, yes? Years pass without gaps being filled in for access to core Rhino functions for Grasshopper users.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2020   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service