Grasshopper

algorithmic modeling for Rhino

Difference between GH python component and python in Rhino

Hello, really basic question! Apologies in advance :)

I have just started trying the GH python component, but I am not getting the correct behaviour when compared with Rhino python.

For example, rs.IsObject of the sample model I attached should return true.

But in GH, the exact same setup gives me false for some reason...

I've attached both 3dm, and gh, and the code. Enlighten me please!

Views: 2190

Attachments:

Replies to This Discussion

Hi Tim,

Not all rhinoscriptsyntax functions can be used in ghpython component.
IsSolid being one of them. I will report this to mcneel guys, as making it work with ghpython too is doable.
In the mean time use the edited function in the attached file (you can also use the "GUID" parameters, but in that case you will have to switch between Rhino and grasshopper documents).

Attachments:

Hey, thanks a lot! That works great.

Though now I am confused. What's the difference between object_id and GUID?

It's the same. It's just "object_id" is another name for GUID in this case.

So in the above attached function, I could have written: IsObjectSolid2(GUID) as well.

But grasshopper's "Guid" parameter retrieves objects_id (or guids) from Rhino document only.

and the object_id you use in the code you sent me refers to the actual grasshopper component?

object_id is a function parameter. You are actually referring to the "b" argument, right?
Yes, it is a guid from grasshopper document (each time you reference some geometry from Rhino to Grasshopper, by using some grasshopper parameter(Brep, Point, Surface, Curve...) you are actually coping that object from Rhino to grasshopper document).

This is what I meant by "but in that case you will have to switch between Rhino and grasshopper documents" (check the attached file).
But it currently has a bug of not supporting Extrusions.
So it's better to stick with sample2.gh solution for now.

Attachments:

You could also pass the geometry as RhinoCommon objects and call the IsSolid (for breps) and IsClosed (for meshes) object properties directly, see attached file. As a rule of thumb I find it less clunky to use RhinoCommon directly when using GHPython. You can avoid operating on guids more or less entirely this way and often the execution speed will be faster as well. Hope Djordje agrees ;)

Attachments:

Yes, djordje agrees :)

Thanks to both!

So when you pass the GH copy of the object as is (like as a brep instead of the id string), the list of methods available to that object is a part of RhinoCommon?

Is there a manual that details the relationship between RhinoCommon (what is it anyway), and the scripting environment? (really dumb question..i know). And how do you decide which to use?

Yes, that's correct.

That said. The rhinoscriptsyntax Module is a Python module which wraps around the RhinoCommon SDK. So when you use rhinoscriptsyntax functions you are indirectly using RhinoCommon already. If you want to inspect the rhinoscriptsyntax module to see how functions implement RhinoCommon you can check it out on GitHub or locally on your machine, something like this:


C:\Users\UserName\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rhinoscript

The problem I described above is that these functions are designed to operate on guids (geometry etc. in the Rhino document) and not RhinoCommon object types. Hence you will have to coerce guids to get their objects etc. This can be quite clunky, it can be slower and it also does not take advantage of the object-orientated architecture of the RhinoCommon SDK. If you search the forum you should see several threads on this subject. Secondarily some functionality has yet to be ported, so you might be missing certain functions.

In general I would recommend to use RhinoCommon whenever you are not dealing directly with the Rhino document (there's a lot of great functionality in rhinoscriptsyntax for getting geometry, looping through layers etc.). The RhinoCommon documentation is available on-line here:

http://4.rhino3d.com/5/rhinocommon/


There's also a nice collection of examples available here:

http://wiki.mcneel.com/developer/pythonandrhinocommon


Hope that helps :)

Hi guys,

I see what is going on.

This function was written for Rhino 4 and now it is buggy. Besides the problem with GhPython, there is something wrong even more in general: try it on a normal extrusion object (like a box) in Rhino and it will return false.

I'll get it fixed ASAP

Thanks

Giulio

--

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

Hi Giulio, will this fix the issue with Extrusions?

Yes -- but unfortunately it will not fix it for GhPython. Checking against a precise type is not entirely Pythonic anyways. "The most Pythonic way to check the type of an object is... not to check it." more...

Giulio

--

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

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service