Two 'rotation' components, but only one available in GHPython lib?

Hi all, I'm wondering if you could help me with an odd issue. I have been using ghPython lib for some tasks and all has been working well, however, a small problem came up. Grasshopper seems to contain two 'Rotate an object in a plane' components (same name, in Transform-->Euclidean). One, the one which I am using, allows for rotations from an initial direction to a transform direction, rotating along the object's center point. The other just allows for rotation based on radian angle and plane. The problem is that ghPython only seems to have the second component, and not the first. I have also not been able to find a Rhinoscript syntax option for this type of functionality.

Could anyone point me to the right direction as far as any of the following: 1) does this ghPython component actually exist but by a different name, 2) is there any way to achieve the same functionality through the other ghPython components, or 3) any way to achieve this through an equivalent Rhinoscript syntax function? Thanks for any help!

ghpython lib only has one version of 'Rotate', without the rotate by direction:

I would like to find the functionality of this tool:

Replies to This Discussion

Permalink Reply by David Rutten on February 16, 2017 at 3:39am

You'll have to create the required Rhino.Geometry.Transform yourself. One of the static methods on Transform allows you to set a rotation using a source and target vector.

I'll see about renaming one of them to this conflict disappears.

Permalink Reply by David Rutten on February 16, 2017 at 8:08am

I renamed the component to Rotate Direction.

Permalink Reply by Andrew M on February 16, 2017 at 9:33am

This is great, thanks David. Would I just download the ghPython lib gha file again or will this just be available in the next round of Grasshopper updates?

Permalink Reply by David Rutten on February 16, 2017 at 11:48am

You'll need the new Grasshopper, python merely harvests those names from the Grasshopper database, so updating python won't do anything for you.

Permalink Reply by Andrew M on February 16, 2017 at 8:31pm

Understood, thanks again.

Permalink Reply by Andrew M on February 17, 2017 at 5:35am

Hi Tom, thanks for your post, I'm probably missing something here but when I enter the script you gave me into the IDE, an error comes up because it does not recognize the variable 'geometricalBasedObject'... I am very likely making a mistake (either you didn't intend this to be input directly into the IDE, or I'm missing an import module). Image below.

Honestly I try to avoid ghcomp and use rhinoscript whenever possible but I'm just more familiar with the application of GH components and sometimes get lazy. I encounter odd problems with typehints or have to take convoluted paths to achieve what a one line ghcomp script can achieve. With time I hope to nurse myself off of ghcomp and fully into rhinocript and rhino common.

Permalink Reply by Andrew M on February 17, 2017 at 6:19am

Thanks, that's a very good point you make regarding strongly typed languages-- if Python was not so incredibly useful and convenient for so many other projects I use it for outside of Rhino, I'd commit to learning c#.

Also thanks for explaining how to use your code, very helpful and I should make more of a habit of trying to use this type of method!

Permalink Reply by Anders Holden Deleuran on February 17, 2017 at 6:21am

A quick tip regarding this: In dynamic languages (ie. that by definition are not statically typed) a key thing to pick up early on is how to use type introspection on the fly. A couple of standard Python functions I constantly use for this are type(), help(), dir(), and isinstance(). Duck typing is another concept that is pretty relevant here.

Edit: Might not be clear from the Py docs, basically just pass your RhinoCommon object to these functions and they'll return what you're dealing with and all the information you would otherwise have to look up in the RhinoCommon docs.