Why doesn't the GH "Pull curve" accept meshes and Sub-Ds?

…While Rhino’s version does ?

OK, this doesn’t seem to raise much interest.
Anyways, I used a kind of “Geodesic on mesh” tool from the “Meshpath” plugin, and it kind of did what I needed.
Funny that’s not a standard tool, as creating geodesics is the basis of a lots of good stuff…
I know it can be done with Kangaroo, but yeah.

C# to the rescue ?

private void RunScript(Curve c, Mesh m, ref object A)
  {
    A = c.PullToMesh(m, Rhino.RhinoDoc.ActiveDoc.ModelAbsoluteTolerance);
  }

PullCurveToMesh.gh (4.9 KB)

3 Likes

I hate C#, but I love when a C# geek pops up with such components.
Yet, this still begs the question : if it’s so simple to make a more potent component directly using the Rhinocommon tool, why didn’t David do it in the first place ?

Some components were created before RhinoCommon existed. Why it hasn’t been updated yet is another subject :smiley:

…Like the Patch Surface tool ?
I’d be damned if it didn’t exist when the GH component was created.

As a matter of fact, I can clearly remember that David Rutten taught me how to use the Patch surface tool in person when he was an intern where I worked, and that was way back in 2001, long before he was even hired by McNeel !
:slight_smile:

Asking "Why … " on rhino/gh can always lead to an “Because rhino is cheap compared to other software, licence is perpetual, code is accessible, devs are helpful and present, etc etc” answer.

Rhino commands with all their variations are a lot.
GH have a fraction of those. It’s not like GH overall lose its usefulness if devs didn’t translate all the commands. For 99.9% use case scenarios, we have everything.
And, as said, rhino code is accessible, as magicteddy shown you.


For a Patch with more options see:

1 Like