Compute Hops Planes passthough

[Andrew_Murray]

Hello,
I have been working with Rhino compute using hops.

I am working on passing a grasshopper file to a local rhino.compute server. And what I found with passing a plane in, and evaluating the definition of the plane before and after executing the compute has me racking my head.

Passing the Plane to the compute server as geometry. The definition of the plane changes both in position and orientation. While inside the GH file sent to the server, nothing is happening, and is just returning a plane that was passed in.

My thoughts are that the world space coordinates are different in rhino compute than in rhino desktop.
Rhino version: Rhino 7 SR34 2023-9-24 (Rhino 7, 7.34.23267.11001)
Hops Version: v0.16.2
Compute: Compute 1.0.0.0, Rhino 7.34.23267.11001

Here is how I have the grasshopper file set up which calls hops, and the contents inside the grasshopper file are sent to the compute server. And what it visually looks like.
Working File:

File sent to Compute

Visualization of Planes using Vectors (Blue vector is Z Axis)

Any Thoughts on this would be helpful.

Thank You

[maje90 (Riccardo Majewski)]

Get Geometry component does not support planes:

what is happening is a subtle conversion/cast from plane to surface…
Here you can see the same error without even using hops:

The conversion from surface to plane is actually a double conversion: surface>curve>plane

re-extract you correct plane by evaluating the surface at 0,0 inside the Hops …

---

Remotely similar argument here: Grasshopper Player defects
(which is marked for 9.x …)

@AndyPayne @stevebaer @DavidRutten

Get Geometry component could be better if able to accept more types of geometries (Line, Plane, Vector, Transform…) , particularly when for deeper use with Hops.
Maybe a “Get Data” which just preserve the original type can be done?

---

Side note, probably more related to GH2:
a user visible explicit feedback of when an item is converted due to param type would be useful
(string>number , line>vector, point>plane, etc etc)
… maybe it’s already planned, I’m not informed about Gh2…

---

EDIT:
this is also related to this:

WISH: different clusters

Hi all. Problem: working with datatree is fine, but with very complex datatree one might spend too much time aligning the data instead of actual coding. Current clusters: just a portion of the whole definition, no difference from normal workflow. Hops: we can set inputs to work as item, list (or datatree with some trick), but the problem is you can’t see the script working while editing the content of hops (it’s another .gh file!) You can’t explore/test the hops code until you run everything…

Programming and editing .gh documents for Hops are much more “distant” from user experience, compared to normal gh programming and clusters. You can’t see what is going on.

In this case Andrew was not able to see that Get Geometry (iPlane) is outputting a surface instead of a plane. Nobody can.
When you open it, everything is orange with no data.

@Andrew_Murray

And if, while editing its code, you pass a plane to it, it seems to pass it correctly:

but this would not really happens while inside Hops.

Hops can be better.
We are seeing an incredible potential (for simpler managing complex datatree) but we are not there yet.

[AndyPayne]

In Rhino 8, the latest Get Geometry component does accept many new data types (see below).

In addition, there is now a dedicated Get Plane component which will properly handle passing Planes into Hops. Rhino.Compute was also updated in the latest Hops release 0.16.4 to handle plane inputs and return plane geometry.