Not able to disable conversion on the Synchronous Sender

Hi guys,

Is there a special reason I am not able to “Do Not Convert” on the Synchronous Sender? e.g. I can do that on the Synchronous Receiver.


For context, I am using Speckle from Rhino.Compute/Hops and since the conversions usually happen asynchronously or sometimes require a Rhino.ActiveDoc, I am disabling all conversions and doing them manually (as exemplified here).

1 Like

Not sure that’s intended. @AlanRynne just looked into some other regressions around our menus earlier, so he’ll jump on this when he has the time!

1 Like

It is most definitely intended! :smiley: We need to ensure everything is converted to Speckle before sending, so it would make no sense to add that option. The normal Sender also doesn’t have it. :+1:t3:

1 Like

What about “Do Not Convert” and throwing a type exception if the data is not good?


1 Like

Could you give us more details of the use-case for this?

We’re assuming that if you get to the point to “Send to Speckle”, you’re going to want everything converted (even if you forgot!).

The main reason for the “Do Not Convert” option was double:

  • Allow for the creation of Speckle Objects that contain Rhino objects in their properties.
  • Allow for the reception of data as Speckle Objects with no conversion.

The first was to allow for users to create complex speckle objects, but still use the powerful Rhino geometry classes (specially inside C#/py scripts).

The second one was added for mostly debugging purposes :sweat_smile: many times things would fail, and we wanted an option to manually control the conversion, so we could inspect the Speckle object directly, instead of a failed mesh.

1 Like

Of course. The use-case is that I want to be able to send/receive things from inside the rhino.compute/hops context.

Say my script is a Github Action. First thing is I pull my repo, from Speckle. I process things and then last thing is that I publish my “build” (into Speckle again).

After debugging a bit more today, I found the exception being raised specifically here:

So, in a way the problem is not really of convert/not to convert, but of this line relying on the Rhino.ActiveDoc that doesn’t exist. Same issue we stumbled here.

I am also happy to contribute to these hops/compute related issues if you guys need, just need a little guidance since you guys know better where the project should go.

In the moment I am finishing a research project around cloud computational design services and would love to have Speckle as my intermediate data exchange service.

1 Like

I’m just thinking, if you want to send speckle objects to… speckle, we could try and make that work - perhaps, depending on your research project timeline, even a c# script would do rather than a full blown no-conversion handling in the send component (which would be a bit more tedious to test).

I’d just want to make sure we hit the ball right: everything that will go in that sender from your end, inside the compute environment, is a base-derived speckle object of sorts? If that’s so, this can work out rather fast!

(the main problem is that we can’t really ship foreign objects, we need to control their serialisation… so if a native rhino line sneaks in, this approach won’t work).

Thanks dimitrie, you are right on. No foreign objects needed, as you say: All I need is to send speckle objects… to speckle. :blush:

Ohhh! Yes @vwb, it definitely seems related to that PR… so it may just be a matter of doing the same trick in the GH connector also? As the PR seemed to only be targeting changes to the Converter specifically.

1 Like

Also pinging @Stam, as the Sync components are his creation and he’s more experienced in compute stuff than me. He may know a bit more about what’s going on.

Yes! On the PR I made the converter defaults to the Rhino.ActiveDoc already (if it exists). See:

So line 172 on the SendComponentSync could be safely removed. The thing is how would I say to the SendComponentSync hey, I have this other Doc I want to use.

I am using this lines on my C# nodes:

var doc = RhinoDoc.CreateHeadless(null);

On RhinoCompute you cannot access the active RhinoDoc as there isn’t any and I am not aware of any ways of replacing this, let me know if I am wrong. I know for isntance that you can access the GH_Document using OnPingDocument() safely. RhinoDoc Rhino Compute

I am not sure if the converters can use anything else instead for context? That would make them a bit friendlier to RhinoCompute.


Ok so I’ve been giving a bit of thought to this. I’m guessing the only time RhinoDoc.ActiveDoc can be null is when running headless. If so, is there anything stopping us from swapping the converter logic from

    public RhinoDoc Doc { get; private set; } = Rhino.RhinoDoc.ActiveDoc ?? null;


    public RhinoDoc Doc { get; private set; } = Rhino.RhinoDoc.ActiveDoc ?? RhinoDoc.CreateHeadless(null);

Specially since we do need a document to be set in order for the converter to be happy.

What do you guys think @Stam @vwb ?


That would be helpful :slight_smile:

I have a question though: Is the Converter a single instance shared by all components? I mean, if I converter.SetContextDocument(myCustomHeadlessRhinoDoc) upstream in the definition, will the components downstream use myCustomHeadlessRhinoDoc for conversions?

Each component holds it’s own instance of the converter, so “downstream” nodes won’t be affected.

The reason for each node holding it’s own converter is to support multiple kits within a single file. Granted, there is only 1 kit(The objects kit) currently developed, but we can’t assume there won’t be in the future :slight_smile:

So basically you’d also need a way to pass in a “custom headless rhino doc”? That may get messy… as all conversion capable nodes would need to be able to access it :thinking: .

Since you can pass in a templatePath into RhinoDoc.CreateHeadless, maybe we should add that to our %appdata%/speckle/kits/objects folder and use that template file.

That way any modification to that template would directly be applied in all instances of the converter. What do you think?

I think it’s great! :slight_smile:

1 Like

Ok! This was me just throwing ideas around, so I’ll talk it with the team and figure out a way forward with this. Meanwhile, would my initial suggestion of swapping the converter logic do any good? Or would you rather wait to have it fully configurable from a template?

That would do the trick for now Allan, thank you so much :rocket:.

That and just making sure the components reference the Converter.ContextDoc primarily rather then the RhinoDoc.ActiveDoc.

For example, here:

1 Like

Hey there! I am interested to hear if this worked for RhicoCompute? @vwb @AlanRynne

1 Like