Hi guys,
I’ve been struggling with this one.
I need to output a list with Mesh geometry converted to IGH_Goo previously.
I tried the conceivable GH_Convert methods, but none of them worked so there must be a nuance I’m not getting.
This image shows the output with a List<IGH_Goo>, but the type inside the wrapper is Mesh array, as you can see. I just need to access it. B-)
Thanks
If it’s a C# script, then you’d best stay away from goo. The script components were designed to hide those wrapper classes from the developer.
Outputting a list of meshes from a script component should be as easy as assigning any IEnumerable<Rhino.Geometry.Mesh> to the output variable. Be it a List<Mesh>, a Mesh[], a Stack<Mesh>, a ConcurrentBag<Mesh>, … anything which can be enumerated over.
It’s in C# but it’s a custom component not a script component.
Ah yes, I wasn’t entirely clear on the description, the List<IGH_Goo> was just for debugging purposes, the actual implementation needs to have Tree access. Correct me if I’m wrong but GH_Structure always implements IGH_Goo. That’s my impression from the docs. I guess I’ll try List of Tuple.
I was confused by the first out parameter in your screenshot.
That is correct. That is why the script components use DataTree<T> instead, which has no constraint on T.
If you’re outputting lists of meshes (one list for every SolveInstance() call) then your output parameter access must be set to list, and you should assign a List<GH_Mesh> in DA.SetDataList(int, List<GH_Mesh>).
If you’re outputting a tree of meshes (again, one tree per SolveInstance() call) then your output access must be set to tree and you need to assign using DA.SetDataTree(int, GH_Structure<GH_Mesh>).
and you should assign a
List<GH_Mesh>
What is the reason for using GH_Mesh instead of Mesh ? Compatibility or performance?
I was Using GH_Structure because with the object wrapper I could pass several different types per branch. Aside from the limitation of retrieving the geometry back, it was working pretty good and multi-threading operations were working flawlessly “straight out of the box”.
I ended up using a List<Tuple> and I managed to get the same functionality and data organization, but multi-threading was a pain. (Ties to my other post in the forum).
It seems as though, from the many posts I encountered, yours and other user’s, that the GH_Structure<IGH_Goo> has issues that need to be solved if we’re to use trees of data at their full potential.
Grasshopper has to be able to do a certain amount of things with the data it handles. These include (but are not limited to): formatting and parsing, conversion to other types, serialisation, validity tests, previewing/baking.
IGH_Goo is an interface that adds some of this functionality to any data type, so GH can handle System.Boolean as well as Rhino.Geometry.Brep as well as some plug-in defined type that was designed after GH was compiled.
Also, all data in GH must be nullable, which excludes storing value-types such as bool, int, double, Point3d and Color directly in lists, because those are never null. By demanding an interface implementation, it turns all data into reference types.
The major downside to this approach is that it basically doubles the amount of types involved, you have to deal both with the underlying type and the goo wrapper type. This makes for a lot of additional checking and complication when writing -for example- type conversion code.
There’s other fairly significant downsides too which is why I’ve ditched this approach in Grasshopper2. Under the new system data is stored directly as is (with an optional synchronised collection of bools signifying null-states if necessary). All the functionality needed by GH to handle the data will be provided by a completely separate class, only one instance of which will ever be constructed. These ‘type assistants’ as I’ve called them will provide a much wider array of functionality than IGH_Goo ever did.
