Not able to disable conversion on the Synchronous Sender

vwb · 18 November 2021 09:49

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).

dimitrie · 18 November 2021 11:15

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!

AlanRynne · 18 November 2021 11:41

It is most definitely intended! 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.

vwb · 18 November 2021 13:27

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

AlanRynne · 18 November 2021 16:56

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 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.

vwb · 18 November 2021 17:28

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:

github.com

specklesystems/speckle-sharp/blob/a0ddb6b840211812f3bf5031baa1537b5f6b8563/ConnectorGrasshopper/ConnectorGrasshopper/Ops/Operations.SendComponentSync.cs#L172

    
      
            base.AddedToDocument(document);
          }
          
          
private bool foundKit;
          private void SetDefaultKitAndConverter()
          {
            try
            {
              Kit = KitManager.GetDefaultKit();
              Converter = Kit.LoadConverter(Applications.Rhino6);
              Converter.SetContextDocument(Rhino.RhinoDoc.ActiveDoc);
              foundKit = true;
            }
            catch
            {
              AddRuntimeMessage(GH_RuntimeMessageLevel.Error, "No default kit found on this machine.");
              foundKit = false;
            }
          }
          
          
//GH_Structure<IGH_Goo> transportsInput;

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.

dimitrie · 18 November 2021 22:10

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).

vwb · 19 November 2021 06:28

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

AlanRynne · 19 November 2021 06:30

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.

AlanRynne · 19 November 2021 06:44

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.

vwb · 19 November 2021 10:41

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

github.com

specklesystems/speckle-sharp/blob/a0ddb6b840211812f3bf5031baa1537b5f6b8563/Objects/Converters/ConverterRhinoGh/ConverterRhinoGhShared/ConverterRhinoGh.cs#L72

    
      
          
          
#if RHINO6
                return new string[] { RhinoAppName, Applications.Grasshopper };
          #elif RHINO7
                return new string[] {RhinoAppName};
          #endif   
              }
          
          
    public HashSet<Exception> ConversionErrors { get; private set; } = new HashSet<Exception>();
          
          
    public RhinoDoc Doc { get; private set; } = Rhino.RhinoDoc.ActiveDoc ?? null;
          
          
    public List<ApplicationPlaceholderObject> ContextObjects { get; set; } = new List<ApplicationPlaceholderObject>();
          
          
    public void SetContextObjects(List<ApplicationPlaceholderObject> objects) => ContextObjects = objects;
          
          
    public void SetPreviousContextObjects(List<ApplicationPlaceholderObject> objects) => throw new NotImplementedException();
          
          
    public void SetContextDocument(object doc)
              {
                Doc = (RhinoDoc)doc;

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);
converter.SetContextDocument(doc);

Stam · 24 November 2021 13:12

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.

AlanRynne · 24 November 2021 13:49

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;

to

    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 ?

vwb · 24 November 2021 15:34

That would be helpful

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?

AlanRynne · 24 November 2021 15:45

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

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 .

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?

vwb · 24 November 2021 15:51

I think it’s great!

AlanRynne · 24 November 2021 15:53

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?

vwb · 24 November 2021 15:57

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

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

For example, here:

github.com

specklesystems/speckle-sharp/blob/d7ffc2dac8b5e761cae293ace2255803395a67b2/ConnectorGrasshopper/ConnectorGrasshopper/Ops/Operations.SendComponentSync.cs#L207

    
      
            return;
          }
          
          
if (RunCount == 1)
          {
            CreateCancelationToken();
            OutputWrappers = new List<StreamWrapper>();
            DA.GetDataTree(0, out dataInput);
          
          
  //the active document may have changed
            Converter.SetContextDocument(RhinoDoc.ActiveDoc);
          
          
  // Note: this method actually converts the objects to speckle too
            converted = Extras.Utilities.DataTreeToNestedLists(dataInput, Converter, source.Token, () =>
            {
              //ReportProgress("Conversion", Math.Round(convertedCount++ / (double)DataInput.DataCount, 2));
            });
          }
          
          
//if (RunCount > 1)
          //  return;

Stam · 30 November 2021 09:53

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