I can’t answer to python, but for C# only part of this is possible.
You can create a new type inside a script component which implements IGH_Goo or one of its derived types/interfaces. This type will be treated by Grasshopper the way it treats all data. Provided you wrote code for it, this type can be baked, previewed, converted into other types, formatted.
It will not be possible however to deserialize the data, as Grasshopper won’t know where to start looking for the class when it is asked to read one of these in from a file.
The problem is that a different script component won’t have access to the same type definition (because it was declared in an assembly it has no references to), and so it cannot convert it into something it can use. This part may work in Python what with the duck-typing, I don’t know.
If you wish to send data from one script component to another, you have the following options in C#:
Use an existing type, for example string. A lot of data could be converted from and to strings, so this allows you to exchange data through regular channels. However it may not be possible in some cases, or may be so involved/expensive that it’s not worth the effort.
Use a framework type which is accessible from both components, for example SortedDictionary<int, byte>. Both components have access to the type declaration so casting is no issue. To exchange an instance which does not implement IGH_Goo, you should wrap it up inside a GH_ObjectWrapper. That will prevent Grasshopper from trying to interpret your data and possibly changing it.
Create a dll using Visual Studio which declares the type and reference this dll from both script components. But at this point why not do everything in VS?
Write the data to a file on the disk and only share the file location. The other component then reads the data from the disk. This is a bit of a hack though and leads to potential conflicts or collisions.
You can pass anything you like (custom class instances, functions, nested lists, dictionaries etc) between GHPython components, by setting the input parameter type hint to No Type Hint. This is actually one of the things I really like/prefer about GHPython (as opposed to the other scripting components, if I understand how they work accurately). This can also aid in severely speeding things up by not casting/exposing large chunks of data to the GH canvas.
This is not working for any custom type. This will only work for types that implement the interface.
You can see an example of a custom-bakeable entity here:
Please kindly read IronPython in Action, as gently mentioned last week. We unfortunately do not have the resources to distill a whole book, one question at a time.
A .Net interface (such as IGH_GeometricGoo) contains all methods and properties that can be overriden. For methods of a .Net class, methods and properties marked with virtual or override or abstract can be overriden. Python can mask all function names.
Thanks for the help, but what does this had to do with what I’m asking? I’m asking RhinoCommon / GH specific types. I doubt I can find GOO inside “IronPython in action”
I assume some objects can return GeometricGoo some don’t.
When I was “swimming” through the Grasshopper api i found RefObject, with no explanation whatsoever where can I get it. I assume it’s coming from RhinoCommon or RhinoPythonScript but… since there’s no example how can I figure that out. I’m not a programmer and never will become one. I use “IronPython in Action” as a reference this is how I got this far. (I got the goo). I’ll try what @Alain said when I got back home.
If there was a template for creating “custom GH Brep type”, “custom GH Geometry type”, “custom GH tree type”, “custom GH vector type”, etc. and more python examples in the API I wouldn’t have to ask so many stupid (for you) questions.
But there is no need to (and we actually hope that you do not) create a ‘custom Brep type’ unless you actually create a new geometry type.
So, for custom ‘Brep’ type, there is no guide. Custom DataTree is not possible in any language because Grasshopper expects its own trees. There is an example with a new data type ‘tristate’, in the Grasshopper SDK documentation, that I linked above. Also, there is an example in Python with a bakable data type in the link I sent before.
Alain’s answer is generic (because your question was generic), but it won’t mean something for the Grasshopper UI. It may mean something for your (future) components.
In reality, your questions regarding custom types can be entirely Grasshopper-SDK-free. You can just add the types you need, and as long as your components understand each other, they will work perfectly fine with one another.
If you want to program such an operation, you need to learn first. And inevitably you’ll be a developer.
Arguably you are now one already. Just a novice one.
I was printing a lot of things trying to understand what does RefObject require in order to do the Convert or the CastTo
I do not understand why this:
returns Bool instead of Brep?
Logic implies a ConvertTo should result in the product of the conversion and not True or False. If Convert coins ToBankNotes and the result = 0 or 1. The World will bankrupt.
I’ve never used the GH_Convert class before, but notice the “ref” keyword in the function signature, that means to pass in a Brep object by reference, which the method will then modify in-place. Something like this in C#:
Brep my_brep = null;
bool result = GH_Convert.ToBrep(data, ref my_brep, GH_Conversion.Primary);
do_stuff_with( my_brep );
IronPython doesn’t support this syntax directly and has some other mechanism of doing so, you’ll have to search around for the specifics.