how to properly deal with tree GH types and rhinocommon API?

Dear all,

We are working on a GH add-on and currently writing it in C# (we are migrating to F# but that's another story). We are using the rhinocommon api.

I generally tend to register the input parameters as a tree so that I have full control over the "loops". There is a big difference however in how data is provided compared to registering it as item or list. I suddenly have to cast everything (see code below for comparison).

Am I missing something?
Does the casting have performance impact?
Is there another more elegant way?

Cheerz,

Wei Pien

with item input parameter (no casting to Rhino types):

input

pManager.AddPointParameter("p", "p", "p", GH_ParamAccess.item, new Point3d(1, 1, 1));
pManager.AddPointParameter("p", "p", "p", GH_ParamAccess.item, new Point3d(9,9,9));

output

pManager.AddLineParameter("line", "line", "line", GH_ParamAccess.item);

Point3d p1 = new Point3d();
Point3d p2 = new Point3d();

if (!DA.GetData(0, ref p1)) return;

if (!DA.GetData(1, ref p2)) return;

var line = new Line(p1, p2);
DA.SetData(0, line);

with tree input parameter, however, I have to cast:

input

pManager.AddPlaneParameter("Plane", "Plane", "Planes tree to slice with", GH_ParamAccess.tree, Plane.WorldXY);

GH_Structure<GH_Plane> plane_tree = new GH_Structure<GH_Plane>();

if (!DA.GetDataTree(0, out plane_tree)) return;

for (int b = 0; b < plane_tree.Branches.Count; b++) {

List<GH_Plane> plane_branch = plane_tree.Branches[b];

for (int i = 0; i < plane_branch.Count; i++)

GH_Plane gh_plane = plane_branch[i];

// Cast to Rhino type before rhino common can be used

Plane rc_plane = new Plane();

gh_plane.CastTo(out rc_plane);

Replies to This Discussion

Permalink Reply by David Rutten on July 7, 2017 at 4:10pm

If your looping behaviour is different from Grasshopper, then getting trees is your only real choice. (How is it different?).

However almost all components that consume trees fall into one category; tree management. It's only if you want to modify the topology or ordering of data that you'd typically get trees directly, and in those cases you don't really care what the actual data is, you're only interested in shuffling it around. This is why there's no easy way to automatically cast trees to simpler types. Another reason is that a tree can only contain data which implements IGH_Goo, and usually the simpler type you're interested in doesn't qualify. So automatically casting a GH_Structure<GH_Plane> to GH_Structure<Plane> is impossible, because Plane is not a type of IGH_Goo. You can of course write a static helper method for quickly converting GH_Structure<Plane> to Plane[][] or List<List<Plane>>, but you'll lose your path structure and you also won't be able to carry over the null items if you're converting to a value type at least.

Someone, somewhere is going to have to do the casting, it doesn't really matter if it's you or Grasshopper performance wise. In fact you may be able to do it quicker since you know in advance exactly what you're converting from and what you're converting to.

The only bit of good news I can give you is that this should become a lot more flexible in Grasshopper 2. IGH_Goo is gone and trees are a lot more mature in terms of converting, duplicating, iterating, enumerating, .... functionality.

Permalink Reply by WP Lee on July 7, 2017 at 6:26pm

Let me rephrase it indeed. Our components should both be aware of the tree structure (our implicit data "model") and be able to manipulate/generating the actual data accordingly. So you're right about the iteration part which should be same. Maybe we should migrate to a custom data type (e.g. list of lists of rhinocommon objects) that can be exchanged between our own components and create break out/in component to interface with standard GH components if required. Can components deal with custom object input/output parameters? I haven't dived that deep into the GH class structure yet.

Any idea what the overhead is of the IGH_Goo casting methods? We currently done cache and have to deal with quite some data of elements (can fill 8GB of RAM very easily).

I'm not sure what GH2 is since I read somewhere that everything above a certain version 0.xxx was considered GH2. Furthermore, the actual plugin we use has the name grasshopper2. AFAIK we still have the IGH_Goo, so that i guess that that isn't the GH2 you mentioned.

Permalink Reply by David Rutten on July 7, 2017 at 11:40pm

Can components deal with custom object input/output parameters?

Yes you can define your own IGH_Goo types. There's some example code in the API documentation for this (download via the help menu).

Any idea what the overhead is of the IGH_Goo casting methods?

It's pretty fast, but not insignificant, especially if you're converting 8GB worth of data. Most parameter types define a most likely conversion (GH_Plane -> Plane, GH_Number->double, GH_Curve->Curve) which is always invoked first. Only when that one fails do slower but more flexible conversion methods come into play.

I'm not sure what GH2 is since I read somewhere that everything above a certain version 0.xxx was considered GH2.

I don't know where you read that, but it's not correct. Grasshopper 1.0 (the only version anyone apart from me has ever seen and used) is what you're using now and will be using for the foreseeable future. On Rhino5 all GH1 versions start with 0.xx.xxxx, on RhinoWip all GH1 versions start with 1.0.xxxx. GH2 is a total rewrite and it's not functional yet.

Permalink Reply by WP Lee on July 28, 2017 at 10:32am

Creating a IGH_Goo type seems pretty straightforward. I haven't looked at the serialization yet since in most cases one doesn't need it. Tnx

Permalink Reply by WP Lee on July 29, 2017 at 6:02am

Tnx, Tom. We already managed to create a F# GH addon project and item template for MS visual studio in the most straightforward manner (including filename/class "rename" and guids generation). We used McNeels C# templates as an example for settings and such. We even used vsix packaging for simple internal distribution and install.

Surprisingly, worked right away. The only difference are the assemblyinfo and componentinfo, in F# somehow always expect either a namespace or module name, while the C# counter part doesn't. So I'm not sure what impact that has, but everything seems to work fine. I'm growing more enthusiastic about F# for Rhino/grasshopper plugin/addon and MSVS2017 is getting there to support F# better. Still missing basic IDE functions like e.g. refactor.

We haven't got to dynamic parameters yet but there are other ways to deal with.

We might, however, have to implement the serailization for our custom Goo type at some point. What I learned from a team member is there is a chance that it has to "ripple down" right to most basic type of the custom Goo type struct of other types and collectibles. We'll see.

Permalink Reply by WP Lee on July 30, 2017 at 5:06am

Ah, you built an actual F# script component. That's much harder to do I guess. In my opinion like the other script components, it become very convenient and powerful if the editor (including some level of "reflection") is supporting language well. I'll have a look again since I could find any link the component nor the source the first quick scan i made. Cheerz

RSS