Cannot convert from Goo to Model

Grasshopper Karamba3D
1

Hi I am trying to use my own script (i.e. the model build is done in code) and am trying to wire up the output with the Karamba Model and Analyze components, however, when I do i get the error “Data conversion failed from Goo to Model”.

My script is in C# and wrapped in a simple C# grasshopper component in which the output is a “Generic” item. I believe what is happening is that grasshopper is wrapping the Karamba Model type and the Karamba components don’t unpack these wrapped types (I believe the wrapper type is GH_ObjectWrapper.

I’m wondering:
a) how do i prevent the wrapping? I have a very simple output…

    protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager)
    {
        pManager.AddGenericParameter("Model", "Model", "Karamba3d model", GH_ParamAccess.item);
    }

b) is there something I can do in grasshopper to unwrap and use the Karamba3d components (i.e. i just want to link it to the simple Model component so that i can continue the Analyze process in grasshopper rather than C#)

2

Hi @Mike26,

for registering the output-plug you need to provide this:

pManager.RegisterParam(new Param_Model(), “Model”, “Model”, “New model based on inputs”);

To read in the model from the first input-plug use e.g.

da.GetData(0, ref inGHModel)
Model model = inGHModel.Value;

At the output the k3D model needs to be wrapped like this:

var outGHModel = new GH_Model(model);
da.SetData(0, outGHModel);

Does this work for you?

– Clemens

3

From which namespaces are

Param_Model
GH_Model

Are these Karamba specific? I am using the nuget package KarambaCommon (unsure if this includes anything grasshopper specific)

4

Param_Model and GH_Model are in the namespace ‘Karamba.GHopper.Models’ which can be found in ‘karamba.gha’ in the installation folder of Karamba3D. The nuget-package contains the parts of K3D which are independent of ‘RhinoCommon.dll’.
– Clemens

5

So I need to reference the karamba.gha assembly in my .NET project?

6

I added a reference to the assembly but it was failing to load (unsure if this is due to the .gha extension?). I renamed the file to .dll just to see if it would load the assembly at runtime and this worked (but can’t be right?!).

I now see the error
image
I did try install the 3.0.0 beta build but later reverted back to 2.2.0 so I think there is likely a mismatch in what is being loaded by grasshopper and what I am referencing in my project.

7

Ok I have resolved my references, yes I had incorrectly installed 3.0 alongside 2.2 and there was a mismatch. I have uninstalled 3.0 and am now referencing the .gha assembly.

However, I still get the error above.
image

In code I have:

protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager)
{
     pManager.RegisterParam(new Karamba.GHopper.Models.Param_Model(), "Model", "Model", "New model based on inputs");
}

and to set the output:

DA.SetData(0, new Karamba.GHopper.Models.GH_Model(model));
8

Hi @Mike26,

the error you encounter indicates, that ‘karamba.gha’ has been loaded twice into memory.

In Visual studio it is not possible to reference ‘.gha’-files via the UI. Instead one needs to open the project file in a text editor and manually add the reference (see this for details)

Make sure that ‘copy local’-option is set to false in the settings of the ‘karamba.gha’-reference.

A last resort is to unhook ‘Memory load *.GHA assemblies using COFF byte arrays’ via ‘GrasshopperDeveloperSettings’ in Rhino. This can be done also for each plug-in individually.

– Clemens

9

hmm I wonder if this was my issue:

Grasshopper loads plug-ins according to the alphanumeric order of their file-names. If a component intends to use Karamba3D functionality make sure its name comes after “Karamba3D” otherwise it will not be able to reference it.

Initially I had set the the reference to the gha manually and selected copy local no. But when loading my plugin it was unable to find karamba.gha… that’s when I switch to trying to copy and load it.

I think even though the karamba.gha was copied (i.e. result in 2 versions) my plugin was failing to load because karamba.gha was not loaded first. I expected when I renamed it to .dll it was able to find the dll but loading this caused the clash when grasshopper loaded the actual .gha.

I’ll see if changing the name to load it second will work… bit annoying.

10

I’m not sure that it just comes down to the name. Grasshopper does try to load my plugin before Karamba, I’m not sure if it is configured to load from certain paths in order? (i.e. Plug Ins → Library Folders → Yak Folders)

11

Did you plug-in work when you renamed it, so that it alphanumerically comes after Karamba3D?

I found this link regarding the loading-order of gh-plugins: What dictates the load order for Grasshopper Plugins? - #2 by DavidRutten. You could try the approach proposed by Jon which involves splitting up the plug-in.

– Clemens

12

ooo boy seems rather difficult. No renaming did not help as my plugin was still being loaded before karamba. I can’t see how splitting the plugin would work, is it suggesting that if I have a separate dll which references the karamba.gha and effectively expose those karamba types, this could be referenced by my .gha and would not be loaded until the symbols were checked? so as long as the symbols aren’t public these should just be loaded on first use of the component? seems very hacky…

Would it not make more sense for karamba to split the public types used in the .gha into a dll that both we developers can reference and the karamba.gha can reference (and maybe release this as a nuget package)? I.e. keep all the component logic etc away in the .gha (as this isn’t really code that would be used by others) and just expose the types such the custom components using karamba can play nicely with the karamba components? I think this would work no?

13

I can’t seem to get this to work, I thought it may load these symbols lazily, but it doesn’t.

14

@Mike26,
I see. You are right. I will try to split off the public types of K3D into a separate ‘dll’ in the next service release of version 3.

The problem will be that it breaks existing code, but in the end it seems to be the better way to go for the future.

– Clemens

15

That would be great! Do you have any idea as to how long until the next service release?

16

I hope I can get it out by the end of next week. It depends on whether unforeseeable problems arise or not.
– Clemens