What a nice bit of alliteration to start off a rainy Tuesday, eh?
For reasons unknown, I’d like to create a custom Contextual Component. IGH_ContextualParameter is available in the default Grasshopper Library. But Grasshopper doesn’t seem to recognise it as a Contextual Component when I implement this alongside GH_PersistentParam<T>. Butternuts.
I’ve discovered that the real meat and bones is sequestered away inside the CurveComponents.gha plugin which has an abstract class called ContextualParameter<T>. The only way I can access this is to reference that plugin into my project. Which works! It’s completely identical hurrah!
So. Questions. Questions. Questions.
Do I need this abstract class? Are there other ways? Is Grasshopper/Rhino or whoever internally checking for this abstract class when GrasshopperPlayer is called?
1.1 If I do need this class, is there a better way to package/reference it? Or can I rely on it always being there?
Is what I’m doing a supported/expected idea, or should I avoid such tomfoolery?
Hey Callum. I spoke with Steve about your questions. In general, these components weren’t really designed with the intent of 3rd parties extending them. It would probably be best to figure out what it is you’re trying to do and then we can either implement it ourselves or get the classes structured so that you can properly implement this without us accidentally breaking our SDK because you’re using something we didn’t really intend to be public. Does that makes sense?
So, this should already work with the Get Geometry component. I know we didn’t expose the Plane as one of the object types… but I just tested a really simple example (see attached) and it does work with the GH Player.
I did try this, and it does work. But it doesn’t prompt a user to create a plane, a user can’t exactly (as far as I know) create a plane in Rhino to select later. And I need to get a plane oriented in space
Ah. I see. The Get Geometry prompt doesn’t let you create a plane, but you can select one already made. Rhino does have a Plane command although it really just makes a planar surface. Still, maybe this could be used for your purpose?
As you’ve rightly described, Rhino doesn’t really have a native way to create a “Plane” within the Rhino context. Is this why you wanted to make you’re own Context Component? Hmm… I need to think about this some more.
In talking with Steve, it does appear that we do have a RhinoGet.GetPlane method which might work for what you want… so it’s probably doable from our side. Is there a rush on your side to have this implemented ASAP? I can’t make any promises but I have added a new YT for this issue.
Just another idea if you could use it.
Taking 3 points using the GetPoint and then running those to make a plane defined by three points has been my work around. 1 for orgin, 1 for x and 1 for y. Same deal as running the cplane command in Rhino. I could be miss-understanding the topic.
+1 for a Get Plane contextual component. We are using the workaround that Ryan described by converting a plane’s origin, x vector, and y vector to three points, then reconstructing the plane upon input inside the hops component, but that is not ideal. Some have already talked about writing our own Get Plane component, which is how I found this thread.
I do not think your youtrack link works, though I would be interested in tracking the progress of this.
@James_D@csykes I have added a new contextual Get Plane component which should be available in the next stable 8.1 release (should be 2 weeks from now). I need to do a bit more testing, but I believe everything is in order. I will also need to release a new build of Hops because there was a minor change that was added to rhino.compute in order to support this new component. Still, everything should be available in about 2 weeks.
I could be miss-understanding the topic.