accessing the GH components through the (node-in-code) ghpythonlib.components

hello there

I am kinda new to GHpython, and stuck trying to find a way to calling GH components directly through python

I've tried to look for documentation of the ghpythonlib components and their classes/or definitions of those functions and arguments to pass, but didn't find much on the net, appearently python for grasshopper is still in its early stage, thus there hadn't been much effort to document it all through, even the source code isn't available.

now I am stuck trying to emulate (write similar function) to the gh components, which is time consuming and not so productive

I'd appreciate any help or resource about the matter

thanks

Replies to This Discussion

Permalink Reply by djordje on July 15, 2015 at 12:53pm

Hi Cristo,

Would you elaborate a bit more on what do you mean by "calling GH components directly through python"?
Do you want to access grasshopper components through a ghpython component or through Rhino Python editor?

In both cases, check these two topics.

And no, other than this, the docstrings when you access the grasshopper functions, and examples on forum, there is no additional documentation on node-in-code.

Permalink Reply by cristo on July 15, 2015 at 1:44pm

thanks djordje for replying

well, I am trying to access grasshopper components through a ghpython component

the situation is that I have a big algorithm (a chaos) with redundant procedures, copy/pasted all through it (clusters are not a big help either), what I am trying to do is not only to shorten this algorithm, but also finding new ways to express the same procedures through code, while giving it a high level of abstruction

the topics you linked are great, but don't encompass the full range of GH components,

so for the time being I guess, I've got to look for the VBScript or c# equivalent doc, they might be of some help

thanks alot

Permalink Reply by Nik Willmore on July 15, 2015 at 3:22pm

As I delved into Python I was quite confused until a singular clarification hit me like a ton of bricks: that Grasshopper was just Rhino for most components and also that Rhinoscript itself was something I could totally ignore, both in favor of focusing on just doing "import Rhino" and then sticking mostly to the Rhino.Geometry namespace in the Rhinocommon.chk reference help file, where my familiarity with using Rhino commands means I can think normally despite the different names and detailed input formats the commands have, now that I know that each COMMAND is written in Python as Rhino.Geometry.COMMAND. No more confusion and no more weird errors burried in long Rhinoscript source code files. Also, no more trees or path mapping!

Maybe not the answer you want to hear, but being free to think fully in real programming mode with the incredible ease with which Python in particular is documented via plain English Google searches for minor and major routines and applications, with peer reviewed and rated answers on programming sites is very liberating.

Most Grasshopper components don't need to be manually emulated, merely looked up in Rhinocommon, but you get to ignore all the convoluted list and tree ones you no longer need, while high level components can still be used on the normal Grasshopper canvas in between Python scripts if you must but mostly just as output modifiers. There's certainly a learning curve diving straight into Rhinocommon but it's an empowering one.

With Python being a perfectly well documented language that is very easy to use thanks to Google and it's own high level behavior, and how Rhinocommon has a solid reference document albeit with too few Python examples (so search for all variations of commands too since some older entries have more Python examples), I'm lately celebrating more than being frustrated. The hard work I must do now pays off since I get a better handle on the stable core of the brain of Rhino which has a lot of its own higher level commands.

Trying to include a node-in-code Grasshopper library that is barely documented and doesn't give you normal error messages and still seems to require some mutant form of data tree considerations, feels like a move in the wrong direction for me personally, as I'm now even avoiding somewhat obsolete Rhinoscript that Python has replaced.

Permalink Reply by cristo on July 15, 2015 at 5:26pm

thanks Nik Willmore

I appreciate the way you made things clear, you trully made a point

It just happens that some of the features I am looking for aren't available in the the rhino.geometry namespace (at least not with the variations and complexity I need), so when I've found that GHpython finally included a node-in-code feature, I though of it as an easy way out to meat my goals,

I have less than a month to complete my thesis, which makes diving into Rhinocommon not the answer for such a short term project, I guess emulating some of those components is by far the most accessible procedure for me (considering the humble knowledge I've gained so far in both GH and python)

thanks

Permalink Reply by Nik Willmore on July 15, 2015 at 7:33pm

Post lots of detailed questions then, since lots of us would enjoy doing some work to learn more about scripting Grasshopper components that are not available as Rhinocommon, such as Voronoi.

Permalink Reply by Paul Alain on December 9, 2015 at 11:06am

Hello,

Just posted a thread similar to this one here.

So I guess the moral of the story is go back to RhinoCommom and Grasshopper SDK and work things out from there, re-implementing some of the great components that are in GH if and when necessary.

Not the best of prospects as I hoped that Grasshopper development would have made the source code or some library that exposes the components available for end users.

Who said you can have your cake and eat it?!

Cheers

Paul

RSS