Getting Rhino objects ID in Python (again)

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on May 12, 2016 at 1:43am

Not quite sure I follow what you're going for here. But it does return the GUID's. To inspect them you can either print them in the Python editor or cast them to strings and output to GH: 

Permalink Reply by Gabriele_333 on May 12, 2016 at 3:18am

Thank you Anders,

now, I want to extract the center point from each Brep. I tried with rs.SurfaceVolumeCentroid and it worked (output b in pic), until I've got more points and a for cycle (output c), then what I get are supposedly Goo objects. Why? How could I get 3dpoints as output?

I tried gh.Kernel.GH_Convert.ToPoint3d(), but it didn't work because I passed only 1 of the 3 arguments requested (data: object, rc: Point3d, conversion_level: GH_Conversion) and I have no bare idea what the other two are.

thanks in advance for your valuable help!

Permalink Reply by Anders Holden Deleuran on May 12, 2016 at 3:30am

1) I think you might be seriously overcomplicating things here. Is there any reason that you're are not just piping the geometry from the Rhino document to the Grasshopper document and operating on it from here? Operating directly on Rhino objects can be rather cumbersome and slow (going from GUID to geometry types, deleting/replacing etc.). Maybe describe what it is you want to do in more detail.

2) Upload your files, no one wants to rewrite your code ;)

Permalink Reply by Gabriele_333 on May 12, 2016 at 4:06am

1) Right. The reason why I am doing this is that piping geometries to GH is currently not an option for my project (I am trying to control RH through an external input) and I don't want to re-reference objects everytime I change / transform one. I provisionally solved the problem through the reference by name block (Elefront) but I am still quite not satisfied as I can not activate the block at my will. So I was about to re-write my function in Python. 

Also, sometimes I love being masochistic :)

2) My apologies, here the file

Permalink Reply by Gabriele_333 on May 12, 2016 at 4:11am

apparently file won't upload... ouch

here a dropbox link:

https://dl.dropboxusercontent.com/u/4927984/test_centroids.gh

Permalink Reply by Anders Holden Deleuran on May 12, 2016 at 8:29am

Hehe, I see :)

If it's because you need to have persistent data (in your case: your objects "remember" where you moved them to) this can be done fairly easily in Grasshopper and would negate having to deal with the Rhino document at all (meaning no GUIDs, being able to use RhinoCommon directly etc). Check out the attached example in which the three breps are persistently translated along a vector each time you press the Move input button. You could do something similar using the sticky dictionary.

Are you sure you need the Rhino document for whatever it is you're trying to do?

Attachments:

• 160512_MoveGrasshopperObjects_PersistentData_00.gh, 12 KB

Permalink Reply by Gabriele_333 on May 12, 2016 at 3:19pm

Thanks Anders,

I tried using RhinoCommon method on my objects but it returned this exception:

Runtime error (MissingMemberException): 'Extrusion' object has no attribute 'GetBoundaryBox'

At least, I am getting closer to my problem's focus. I guess the focus is that I need to find the best way to reference my Rhino Geometry in a way that is automatic and doesn't require the user to manually reference geometries

 WHAT I TRIED: reference by Elefront (not good because it requires a timer and I can not trigger it at my will);

- reference by Elefront (not the best because it requires a timer and I can not trigger it at my will);

- coercegeometry (it gives me the mentioned error when I apply Rhinocommon methods). Of course I could use rhinoscriptsyntax methods after coercing geometry but, apparently, they are missing some cool feature (e.g. rs.boundingbox() doesn't ask me for the bool that sets the precision)

here my last trial:

https://dl.dropboxusercontent.com/u/4927984/test_centroids.gh

Permalink Reply by Anders Holden Deleuran on May 13, 2016 at 2:06am

You've got several issues here it seems:

- The Extrusion type doesn't have a GetBoundaryBox method. It does have a GetBoundingBox method though. Maybe that's the one you we're looking for.

-The issues that I mentioned above concerning casting from GUID to RhinoCommon object (coercing). Leading to:

- Mixing up RhinoScriptSyntax (which operate on GUIDs) and RhinoCommon (which operate on RhinoCommon objects) methods. I would stick with one paradigm (personally, RhinoCommon).

- Referencing geometry from the Rhino document and feeding it to the Grasshopper document (I would recommend the built-in Geometry Pipeline or the one that comes with the Human plugin).

That said, I would rethink your approach. Most of these issues could be negated (edit: in that you could use RhinoCommon directly AND wouldn't have to deal with the Rhino document) if you implemented your algorithm exclusively on the Grasshopper side (as per my previous post). But again, hard to tell without the full scope of what you're trying to do. Hope that helps ;)

Permalink Reply by Gabriele_333 on May 16, 2016 at 4:51pm

Thank so much Anders, I will go with the built-in pipeline and rhinoscript for now. Just one more question: why passing a geometry in Python causes a fault in further converting it to its GUID?

Permalink Reply by Gabriele_333 on May 17, 2016 at 1:37am

Dumb me, GIUDs need to be converted into str when enterying Python!

solved :)

Permalink Reply by Anders Holden Deleuran on May 17, 2016 at 1:57am

Glad you figured it out :) Also, you might want to get acquainted with the dir(), help() and type() Python functions. They're really useful for inspecting data types (objects) and their methods.