New ghPython with Node-in-Code and Multi-threading

Ciao Giulio
Grazie per il tuo contributo per lo sviluppo di Python e GrassHopper
Ciao Vittorio

Hi Thorsten.

“Not iterable” is quite usual when you are trying to iterate through something that is not a list.
Seems like you need to set your “breps” input to “List access” (right click on it).
Apart from that the “Guid” part means you still have your “breps” input set to “ghDoc object” type. Change it to “Brep”. You only use “ghDoc object” type when using rhinoscriptsyntax functions. Ghpythonlib.components require objects of certain type (Brep, Curve, Surface…) to work on.

I was so sure I did that e few time while testing, but you where right.
The list of objects and typehint brep did the trick.

Performance with 693 open breps:

  • standard GH component takes 1.2 sec.

  • non-parallel Python takes 1.3 sec,

  • parallel Python takes 0.45 sec.

Yep, it looks like this needs tuning up. The name is actually _1 which is pretty lame. I figured this out by printing the SortList output to a small list and looked at what was placed in the output.

Ah, nice. Did not know that when an output of a function is in a form of a tuple, you can get the names of tuple items, by printing it:

a = ghc.SplitList(someList,2)
print a

prints:

Output(_0=<Rhino.Geometry.Point3d object at 0x0000000000000075 [-4.08513357560264,-6.40207500654145,0]>, _1=[<Rhino.Geometry.Point3d object at 0x0000000000000076 [-14.4503978719078,-4.93874357647483,0]>, <Rhino.Geometry.Point3d object at 0x0000000000000077 [-7.86540643660807,1.89013643050272,0]>])

While when function output is just a list, it isn’t named:

a = ghc.Circle(someList,2)
print a

prints:

[<Rhino.Geometry.Circle object at 0x0000000000000084 [Rhino.Geometry.Circle]>, <Rhino.Geometry.Circle object at 0x0000000000000085 [Rhino.Geometry.Circle]>, <Rhino.Geometry.Circle object at 0x0000000000000086 [Rhino.Geometry.Circle]>]

Or did I get this “names of tuple items” wrong?

That is correct, if there is only one output there is no named tuple. It just “felt” a lot cleaner when I put the code together.

Thanks.

Thanks for the detailed reply, really helpful! I am using RhinoCommon calls normally, out of c# … honestly up to the release of the new features I’ve never used python. Just because they can save so much work. You nailed it :slight_smile:

I’ve been running into another problem recently, regarding multithreading of mesh-splitting operations. The performance both in C# and python is great with MT, but the outputs contain errors sometimes

The setup is simple - I have some meshes to split (the list to parallelize) and some splitting meshes that should all operate on all of the first set.

Some background of my experiences: In C#, when simply using Mesh.Split on different threads simultaneously the results get messed up quite a bit more often than with python - I understand this, since it has been mentioned that some of the commands are static because they are optimized for performance. If I lock the splitting operation for the time of its execution I of course come back to the single-threaded performance. So no option there up to now.

So I headed for python. I am using ghcomp and parallel. I understood it like that with those, a new context is created for each thread - so the problem of static functions should be avoided. But now the problem I would like to pass to you:
When comparing the outputs of three different versions on the same input meshes, the ghpython parallel version gives slightly different results sometimes! It would be great if you could have a look at the attached sample file…!

Thank you very much,
Robert

testPythonMT_MeshSplit_4McNeel.gh (20.8 KB)

Hi Robert!

I downloaded your ghpython_MT.gh script, and it’s been very helpful to me in trying to set up a parallel alternative to Grasshopper MeshRay component. I was wondering, though - how would you add another output to your Python script to replace the Boolean result that is given by MeshRay?

I’m quite new to Python, and still learning! I would really appreciate any help you could offer.

Thanks!
James

Hi James

if you zoom in, magnifying the component to about 500px, some “+” and “-” will appear, allowing you to add or remove other inputs/outputs.
Thanks,

Giulio

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

I’ve added it using the plus sign, but where and how in the actual code would I add the ability to ouput the boolean results?

See this post about my dilemma:

Hi. One simply question:

How can I create a mesh or polysurface out of these 3D voronoi breps? Not working code below.
I tried to deconstruct the brep … but I really dont know how.

Thanx a lot

import rhinoscriptsyntax as rs
import ghpythonlib.components as ghcomp
import scriptcontext

points = rs.GetPoints(True)
breps= ghcomp.Voronoi3D(points)

for brep in breps:
#scriptcontext.doc.Objects.AddBrep(brep)
#mesh = ghcomp.MeshBrep(brep)
#surface = ghcomp.DeconstructBrep(brep)

rs.AddPoints(points)

Hi ZweiP,

Grasshopper’s Voronoi3D component has two outputs, I guess that’s the thing which caused the trouble:

import ghpythonlib.components as ghcomp
import rhinoscriptsyntax as rs
import scriptcontext as sc

points = rs.GetPoints(True)

breps= ghcomp.Voronoi3D(points)[0]

meshes = [ghcomp.MeshBrep(brep) for brep in breps]

for i in range(len(breps)):
    brepId = sc.doc.Objects.AddBrep(breps[i])
    #meshId = sc.doc.Objects.AddMesh(meshes[i])

In my opinion, it would also be better to open a new topic, for any further issues.

thanks djordje. it works fine.
it is always the same. some minor changes an everything works. in this case [0]. :slight_smile: