GH.Python Moving Breps with RhinoCommon returns Booleans, not geometries

Hi Forum,

Trying to develop my first GH Python Script and hitting a bit of a learning curve.
Watched all the Lynda training a couple of times but struggling to make my own thing work.

The first step of my script is to move inputted Breps.
For the next steps in my script, I need this to be a loop and use RhinoCommon (not RhinoScriptSyntax)
This is what I wrote this far:

# Move up Test
# geo is a bunch of spheres inputted in the component

movedGeo = []

for i in geo:

    vec = rg.Transform.Translation(0,0,100)
    x = i.Transform(vec)

a = movedGeo

For some reason, this outputs a list of Booleans, all true, instead of the moved up Breps and I dont understand why.

Could someone explain this and tell me how to get my moved up Breps instead ?

(Ultimately my script would jiggle a bunch of breps to overcome failing boolean unions but thats as story for another time)


01 Moving Outputs Booleans.3dm (1.5 MB) 01 Moving Outputs (4.8 KB)

Hello Dav,

I think the first conceptual challenge here is to think in terms of objects, not functions. When you move object i It has moved so you don’t need a new list. You can use your old list and it continues to hold your (now moved) objects.

The method returns True to let you know it was successful. You may need a commitChanges method somewhere to update you GrassHopper or Rhino document…


1 Like

Hi there,

Thank you for taking the time to reply.

The adding I to a new list is a workflow from the training files I mentioned. As a total noob I didn’t really question it much but it did seem like a clean way to output specific things from more complex script. In this case though, it serves more as a place holder which shouldn’t impact the attempted .Transform

Had a look at the training file again and they don’t seem to be using commitChange or anything like that, so am still not clear why it works in the example file but not in my version :confused: (See below under #Move)

**import** Rhino.Geometry **as** rg
**from** math **import** radians

distances = []
frames = []


**for** panel **in** panels:

point = panel. **PointAt** (0.5,0.5)
dist = point. **DistanceTo** (attractor)
distances. **append** (dist)
distances. **sort** ()
dmin = distances[0]
dmax = distances[-1]
range = dmax - dmin


**for** panel **in** panels:

panelC = panel. **Duplicate** ()
centreF = panelC. **FrameAt** (0.5,0.5)[1]
dist = centreF.Origin. **DistanceTo** (attractor)
scaledist **=** (dist - dmin)/range ***** (max-min) + min


trans = rg.Transform. **Scale** (centreF.Origin, scaledist)
panelC. **Transform** (trans)


moveDir = centreF.ZAxis
moveVect = rg.Vector3d. **Multiply** (scaledist * 3, moveDir)
moveTrans = rg.Transform. **Translation** (moveVect)
panelC. **Transform** (moveTrans)


rotateTrans = rg.Transform. **Rotation** ( **radians** (viewAngle), centreF.Origin)
panelC. **Transform** (rotateTrans)
frames. **append** (panelC)



Example Files.3dm (44.2 KB) Example (13.6 KB)

Hey there. First could you edit your code to remove the asterisks around the bolded function texts…I can’t read it proper with that.

See in the code, what they do is first to create a shallow copy of each panel.
This is given by the line panelC = panel.Duplicate which creates a shallow copy of the panel, and the geometry. If you want to use a shallow copy method to preserve original geos, then u could make it as such:

sphs = i.Duplicate()

This calls shallowcopy of your spheres.

After which, it works in the way such that each geometry will have a method applied to it. You can look up rhino api for more help on this. When you apply a method, you will be doing an action directly to the object and thus changing it permanently. Hence the non destructive method of creating a shallow copy.

Instead of appending x, you should’ve appended i. Because i is now moved after using a method on it.

I hope this helps. Good luck!

1 Like

Thanks a lot for explaining. My brain was stuck in the Grasshopper way to do things so it didnt compute the basic fact that when a thing is moved, it’s moved. silly me

1 Like

OOP is one of those topics in computer science which generally takes a long time to teach / learn and then seems totally obvious once you have got it :smiley: