Ghpythonlib.components methods are not accepting inputs

Serengeti (Rhino WIP)
, , , ,
1

Hi all, I added this to a previous thread on this subject from August, but thought I’d better raise it as a separate post. In the latest Rhino Beta (8.0.23286.1003, 2023-10-13) and Grasshopper (1.0.0007 from Friday 13/10/23 ).

ghpythonlib.components methods are not accepting inputs in python


import ghpythonlib.components as ghcomp
import Rhino.Geometry as rg

move_vec = rg.Vector3d(10,3,5)
new_geom = rg.Sphere(rg.Point3d(0,0,0), 3.0)


geom_moved, transf = ghcomp.Move(geometry = new_geom, motion = move_vec)

Ghcomp is unhappy with either ordered args or named keyword inputs. So the code below doesn’t work either, which used to…


geom_moved, transf = ghcomp.Move( new_geom, move_vec)

The resulting error:

Traceback (most recent call last):
  File "rhinocode:///grasshopper/1/cbaba2cd-c296-4f63-acb2-eeb5e81bcf39/f5a25331-884d-4b26-be9f-9040a0a1007c", line 11, in <module>
  File "C:\Users\brian\.rhinocode\py39-rh8\site-rhinoghpython\ghpythonlib\components.py", line 163, in component_function
    elif len(result) > 1: result = __namedtuple(outputnames, result)
  File "C:\Users\brian\.rhinocode\py39-rh8\site-rhinoghpython\ghpythonlib\components.py", line 61, in __init__
    raise TypeError(
TypeError: Expected type Array[str] for input 'attributes', got IReadOnlyList[String].

Is this something to do with the Ironpython implementation behind the scenes?

I realise I was being lazy making extensive use of the components library instead of rhinocommon, so if this doesn’t work in Rhino 8 I’'m looing at an extensive re-write of my code. The big shame would be to lose access to kangaroo components though.

Very grateful if anyone has any pointers or work arounds to this,

Cheers,

Brian

2

I’ve just tried this again in this week’s build of Rhino 8 Beta (8.0.23290.13303, 2023-10-17) and still get the same error.

Anybody out there got a step for a hint?

3

Are you using a C Python 3.9 component?

Isnt that NodeInCode, a .Net integration, that most likely relies on IronPython, for the components it does work with.

I don’t know how the C Python component has been integrated in Rhino 8, nor if it does have a bridge into the .Net classes under the hood of Rhino. But I didn’t know C Python in Rhino 8 had even attempted support for NodeInCode at all, and I wouldn’t be surprised if it never happens.

4

oh I see, just checking and the code works fine in an IronPython 2 code window. Sorry, that was not clear at all to me.

Bit of a trade off this, if you use CPython 3 you get the whole ecosystem of true python, numpy, scipy etc. but you lose access to easy utility functions and 3rd party grasshopper plugins.

I wonder if I could mix and match… probably not likely, I am using both Networkx and kangaroo.

5

No probs. Glad you’ve avoided the huge re-write.

I don’t knwo what’s planned or what libraries are available to call from Grasshopper C Python. But you perhaps you could make a Rhino 8 plug-in that uses some GHPython components and some C Python ones, that communicate via native Grasshopper connections, however the user wants to connect them together.

6

Well to be honest I think I still have a massive job ahead of me. I was previously using ghpython remote to make use of xml and networkx. I’m using the graph as a data structure for the geometry I’m generating and storing.

I can see me doing the form finding stuff I want to do with kangaroo in a separated out IronPython node, but I did have a whole set of utility functions for modelling that I was storing in a sticky to access more generally. I have found certain geometry manipulation functions difficult to implement in RhinoCommon, in the case of curve booleans for example I just gave up as I couldn’t get valid results using the rhino common functions - I don’t know what secret sauce there is in the gh components to make these work more reliably.

So I’m left with either entirely encapsulating the Cpython dependent stuff like networkx but then I lose the flexibility of using that to refer to neighbours and the topology of my geometry. Or… I encapsulate kangaroo related work but spend ages converting all the geometry manipulation I was doing with the gh components to Rhino common. This is likely to get messy as I’ll probably run into the same problems I had before with certain functions not giving results reliably. That would mean having some geometry functions on the ironpython side and some on the cpython side.

The reason I was excited at getting access to cpython in Gh was that I was having major slow down with ghpython remote in my Rhino 7 version of this work.

Anyway, just thinking out loud and debating what to do next,

Cheers

1 Like