Accessing ghpythonlib.components from Rhino PythonEditor?

[ivelin.peychev]

What is the proper way to use it?

[ivelin.peychev]

Nevermind, I got it. I misspeleed the ghpythonlib adding s

Still it is more difficult that you don’t see it in the dropdown list after import+space

UPDATE:
ghcomp.ConstructPoint(0.0,0.0,0.0) does not create a point

[ivelin.peychev]

I would expect this:

from ghpythonlib import components as ghcomp
ghcomp.ConstructPoint(0.0,0.0,0.0)

To act similar to this:

import rhinoscriptsyntax as rs
rs.AddPoint(0.0,0.0,0.0)

[AndersDeleuran]

@ivelin.peychev

I would expect this

This is a good example of what I was hinting at here:

Entwine virtual component something's wrong?

That’s true, however I’d recommend against mixing apples and oranges here (i.e. imperative/textual programming with IronPython/C#/VB and declarative/DAG-based programming with Grasshopper) and to mainly/only use the virtual components for calling stuff that isn’t exposed in RhinoCommon or rhinoscriptsyntax (say the Voronoi functions). Mixing paradigms like this will more than likely lead to unnecessary complexity and confusion, both as the programmer (try debugging those calls!) and anyone read…

[ivelin.peychev]

Yeah, when I saw you typing I expected this reply

Still, can you help me. I was never able to cast to geometry. Can’t find the proper syntax.

[AndersDeleuran]

Haha, sorry, I really do tend to beat dead GHPython horses

Afraid I can’t really offer much help here. Giulio would probably be the one to shine some light on this issue. That said, I would expect him to offer the same advice (i.e. don’t use ghpythonlib for this).

[ivelin.peychev]

But isn’t that what ghpythonlib is supposed to be for. I don’t get it. Why spend time and create something apparently beautiful, then restrict all its applications.

@piac, could you please shed some light on this?

[Helvetosaur]

ghcomp.ConstructPoint(0.0,0.0,0.0) does not create a point

It does. Remember you are creating “virtual” geometry, it doesn’t exist in the document. Grasshopper gives you a “preview” of the geometry, but it isn’t added to the document before baking. If you want to add the point to the Rhino document via Python, you can use scriptcontext, which refers to the active Rhino document.

import scriptcontext as sc
from ghpythonlib import components as ghcomp

pt=ghcomp.ConstructPoint(0.0,0.0,0.0)
sc.doc.Objects.AddPoint(pt)
sc.doc.Views.Redraw()

[ivelin.peychev]

Thanks Mitch,

So sc.doc.Objects.* takes care of the baking. I missed that part.

So if I want to create intermediate “hidden” stuff you know like a GH definition with all components blindfolded. I just use sc.doc.Objects.* on the final result that I wanna see as 3d geometry.

Now that is very useful.

Remark to McNeel:
The above code loads Grasshopper and you have to run the script second time for it to actually create the point.

[Helvetosaur]

The above code loads Grasshopper and you have to run the script second time for it to actually create the point.

Well, I have no idea why you might want GH components in a Python script for running inside Grasshopper which has those same components, but whatever…

You also might want to check out the RhinoCommon api docs, most of the native GH components are actually built using those RhinoCommon methods, you can access them directly in your Python scripts inside or outside of GH.

[ivelin.peychev]

ou also might want to check out the RhinoCommon api docs

Yeah, I get lost a lot in there. That’s why prefer to use GH virtual components to take care of all the typing, casting, baking etc. There are too few python examples there and C# syntax is incomprehensible to me.

for example:
say I wanna create a cylinder and convert to Brep using RhinoCommon.

 ToBrep(...)
 |          ToBrep(data: object, rc: Brep, conversion_level: GH_Conversion) -> (bool, Brep)
 |          
 |              Convert data into Rhino.Geometry.Brep.
 |          
 |              data: Data to convert
 |              conversion_level: Level of conversion.
 |          

I’m better off with virtual components

Update: to add a bit info rs.AddCylinder(rs.WorldXYPlane,....
throws an error that rs.WorldXYPlane is not a plane WTF?!

[Helvetosaur]

throws an error that rs.WorldXYPlane is not a plane WTF?!

Try rs.WorldXYPlane()
(with the parentheses)

All of the rs… methods are calls to other functions, so even if there are no arguments, you need a pair of empty parentheses.

You could also have used Rhino.Geometry.Plane.WorldXY

say I wanna create a cylinder and convert to Brep using RhinoCommon.

import Rhino
import scriptcontext as sc

circle=Rhino.Geometry.Circle(Rhino.Geometry.Plane.WorldXY,10.0)
cylinder=Rhino.Geometry.Cylinder(circle,10.0)
brep=cylinder.ToBrep(True,True) #convert to brep + add caps top and bottom
sc.doc.Objects.AddBrep(brep)
sc.doc.Views.Redraw()

[ivelin.peychev]

@Helvetosaur, is there a way to recognize whether to use () or not by just looking at the API? This is the biggest problem I have.

BTW, my point @AndersDeleuran :
Compare this:

import Rhino
import scriptcontext as sc

circle=Rhino.Geometry.Circle(Rhino.Geometry.Plane.WorldXY,10.0)
cylinder=Rhino.Geometry.Cylinder(circle,10.0)
brep=cylinder.ToBrep(True,True) #convert to brep + add caps top and bottom
sc.doc.Objects.AddBrep(brep)
sc.doc.Views.Redraw()

with this:

import scriptcontext as sc
from ghpythonlib import components as cp

a = cp.ConstructPoint(0,0,0)
b = cp.XYPlane(a)
c = cp.Cylinder(b,30,30)
d = cp.CapHoles(c)
sc.doc.Objects.AddBrep(d)
sc.doc.Views.Redraw()

For me 2nd one is absolutely magnificent. No excessive Something.Something.Something and then wondering do we have a () do we not? This is pure python beauty.

[AndersDeleuran]

This is the biggest problem I have.

You’re going to need to read up on and understand the difference between properties and methods (i.e. functions) if you’re going to be programming in a object orientated language (i.e. IronPython and C#) and API (i.e. RhinoCommon, which is what both rhinoscriptsyntax and ghpythonlib simply are layers of indirection around).

For me 2nd one is absolutely magnificent. No excessive Something.Something.Something and then wondering do we have a () do we not? This is pure python beauty.

That should tell you a lot. All those Something.Something.Somethings tells you explicitly from which namespace something came from. To me that is a thing of beauty. Whereas obfuscation and indirection is not. But again, that is in the eye of the beholder I guess

Edit: Also I would probably go like this:

import Rhino as rc
import scriptcontext as sc

xy = rc.Geometry.Plane.WorldXY
crc = rc.Geometry.Circle(xy,10.0)
cyl = rc.Geometry.Cylinder(crc,10.0)
cyl = cyl.ToBrep(True,True)
sc.doc.Objects.AddBrep(cyl)
sc.doc.Views.Redraw()

[ivelin.peychev]

You’re going to need to read up on and understand the difference between properties and methods (i.e. functions) if you’re going to be programming in a object orientated language (i.e. IronPython and C#) and API

I would agree with this if I wanted to create new classes, new types of geometry, but if I need to create just 3d geometry it’s a waste of time. That’s why people use GH in the first place.

That should tell you a lot. All those Something.Something.Somethings tells you explicitly from which namespace something came from.

in the api there are classes derived from the same base class, hence more than one way of creating the same 3d object. This is confusing, especially when they have different methods and properties.

[AndersDeleuran]

I would agree with this if I wanted to create new classes, new types of geometry, but if I need to create just 3d geometry it’s a waste of time. That’s why people use GH in the first place.

This is just flat out wrong (IMO). If one implements an OOP-based geometry API (i.e. RhinoCommon.Geometry) one will have to deal with constructors, properties, and methods. Whether or not these are wrapped in GH components on the canvas, rhinocscriptsyntax, or ghpythonlib. Again, all layers of indirection. And all I’m suggesting here is that one is really ultimately only cheating one self (and causing more confusion) by not at least getting a basic understanding of what is involved under the hood sort to speak.

[ivelin.peychev]

one is really ultimately only cheating one self

Not denying that. It’s just that now I just wanna drive the car, not to be able to design the engine.
When time comes and I don’t need purely the result but I need to investigate other means to get the result. I’ll invest time to find my way inside the API.
This is the reason why I use python and not csharp with RhinoGH. Pragmatism

[jesterking]

If you want to just drive the car you’d be using ready made scripts and not type any code at all at any point.

You writing code means you want to do more than just drive the car - you are making the car, modifying it etc.

So do yourself a favor and listen to the very good advices given by all who told you to learn what you need to learn.

It makes you a better user, and it saves everybody elses time.

[ivelin.peychev]

If you want to just drive the car you’d be using ready made scripts and not type any code at all at any point.

I wanna drive the car myself, and not with predefined gas-break-clutch-shift that someone else has scripted.
To clarify, I mean that I’m ok for now to use ghpythonlib as it gives me enough control. To compare it with say some Food4Rhino plugin where I have none. This is the sweet spot.

It makes you a better user, and it saves everybody elses time.

To make me a better user and save other’s time. Make sure there’s enough Python examples for all API entries. This is existential kind of a problem.

So do yourself a favor and listen to the very good advices given by all who told you to learn what you need to learn.

About that it’s not the lack of desire to learn it’s the time I have. (the lack of it)

[jesterking]

You missed the point I was trying to make. You want to drive the car, sure. But apparently you also want to change your car. And change it with your own cooked up solutions, at that. Not any gas-break-clutch-shift someone else already did.

You want to have the cake, and eat it too… To do that you’ll have to learn. If you don’t have the time now, you will not have the time ever. You’ll have to make time for that. Invest now, reap benefits later. You can have the cake, but once you’ve learned, you can eat it. Not before.

Make sure there’s enough Python examples

There is quite extensive documention here: https://developer.rhino3d.com/api with for instacne WorldXYPlane here https://developer.rhino3d.com/api/RhinoScriptSyntax/#plane-WorldXYPlane (oh, look at that, an API entry example with that, too!)

Then further you have your https://developer.rhino3d.com/guides (not to mention https://developer.rhino3d.com), and of course there is the internet full with the languages you need, like C# tutorials for all kinds of people, and so on.