algorithmic modeling for Rhino

Hey guys,

I want to know how to use the GH_Point method in python instead of using rs.AddPoint.

For example:


for i in range(50):




How can the rs.AddPoint and the append to MyList procedure  be replaced with the GH_Point method??

Thank you in advance!


Views: 98

Reply to This

Replies to This Discussion

hello try this:

from Grasshopper.Kernel.Types import *
from Rhino.Geometry import *

gh_points = []
rhinocommon_points = []

# gh_point or rs.AddPoint is a wrapper for Point3d
# so better go directly for Point3d - see Rhinocommon SDK
# Be aware that Point3d is a struct not a class meaning
# that if do this pt0 = pt1 you always copy, and not
# reference to the same location in memory
for i in range(50):

a = gh_points
b = rhinocommon_points

Hi Tom,

Thank you very much, it worked perfectly.


Quick best practice/tip: I would advise against using the from foo import * style. This not only makes it difficult/impossible to trace the namespace/module a function/class comes from, it can also lead to name conflicts if two (or more) namespaces have an object with the same name etc. More to the point though, within the context of GHPython, you'll be robbing yourself of what little intellisense we do have ;)

The current style I (and I think most of us here) use would be something like (you could of course also import child namespaces):



not being statically typed is what I really don't like on python, which is sold as advantage, but actually is huge drawback in my opinion: Imagine you've got a custom class MyNamespace.MyGeometricalCore.Point and you imported System.Drawing.Point with: from System.Drawing import *. Now you pass that into a method flipcoords(Point(x,y)). This will be interpreted without error, but may cause an error inside your methods definition or even worse it does not create any error but does something different then expected instead. Such things will be extremely difficult to debug. So yes, probably Anders solution is better. You could also do import Rhino.Geometry as rg -> rg.Point3d(). However if you want really safe coding, its always a good idea to write full as Rhino.Geometry.Point3d(). That will make sure its the right one, but it makes your code harder to read. So its always a matter on what's suited best for your task. There won't be a naming conflict between Grasshopper and Rhino and I copied the c# approach on this. so I was a bit lazy here, but because you can produce weird errors like this, I often disagree about the claim that python is so much easier to learn.

I agree. That said, dynamically typed doesn't necessarily imply not being explicitly (as in not being ambiguous) typed (such as in the case here). I personally wouldn't use a statically typed language unless I will be compiling (for the benefits of speed, modularity and compilation errors), but I can certainly see why others would (again, personal preference does matter).



Search Grasshopper


  • Add Photos
  • View All

© 2017   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service