Looking to start a project in the new year and our modellers want to use speckle for data management.
We’ve had issues in the past where our computational designers have become a bottleneck on projects, so I’d like to set up a system where, if possible, our grasshopper scripts are run automatically whenever the modellers push updates from Rhino - current thought is:
- Modellers model
- Modellers push to speckle branch A
- Our server listens for the push
- A rhino compute instance runs, pulling the changes from branch A, doing work, and pushing to branch B
- Modellers get a email when work is ready
Most of that is straightforward, just giving you the full context. The main question I have at the moment, whats the best way to set up speckle to get this to work? Is this even an intended use case for speckle?
One immediate issue I’ve had is that the Synchronous Reciever node is throwing exceptions when it is called within a rhino compute instance:
An exception occurred while processing request
System.NullReferenceException: Object reference not set to an instance of an object.
at Objects.Converter.RhinoGh.ConverterRhinoGh.SetContextDocument(Object doc)
at ConnectorGrasshopper.Objects.SelectKitTaskCapableComponentBase`1.BeforeSolveInstance() in C:\Users\circleci\project\ConnectorGrasshopper\ConnectorGrasshopper\Objects\SelectKitTaskCapableComponentBase.cs:line 142
This seems to be a reference to RhinoDoc.ActiveDoc which has been identifed as an issue in converters: Pull 749.
That being said I don’t want to dive into bugfixing if this isn’t the right direction more generally…
Interested to hear if anyone has been down in this road before and give me some pointers about where I should get started.
This is definitely a scenario we want to support via Speckle. Our long term vision on this would look a bit like GitHub Actions, see this thread by @messismore : Speckle Actions! Suggestions?
Currently, I think what you describe could be, at least in part, possible via Rhino Compute, but I’m not too experienced with it, so I’ll ping some folks who might be able to help you some more: @Stam who created the Synchronous Reciever for use in RC and @vwb who I believe fixed the issue you have with the ActiveDoc (maybe you have an update pending?).
Cheers Matteo, yes I’d love to get input from people familiar with the codebase - I branched it and started making a mess but got about an hour in and decided I was just creating more problems (as I shift in my day-to-day from programming to management this is happening to me more and more ).
I got stuck just 1 step ahead as you @chris.welch. My PR fixed the issue specifically on the Converters, but there are more places where the components are assuming there will be an ActiveDoc (e.g. the SyncReceiver).
I believe if you choose “do not convert” you will walk one step further. The thing is now you will need to convert things manually, that’s very possible and there are examples on the forum (Speckle nodes and Hops - #7 by vwb).
What is not possible, yet, is to disable the conversion on the SyncSender. Meaning you will stumble on the same exception if your workflow needs to send anything back to Speckle.
I had to drop working with this for a while, but intend to come back and contribute if more people are interested.
Would you look at that! Thank you very much for the pointer @vwb!
You’re right though that we can’t actually write anything back to speckle without specifying a converter and speckle trying to ping the rhino doc and crashing. It’d be great to be able to fix as this would unlock so much potential in the short term - I’d like to hear @Stam’s thoughts on how the nodes are working currently…
Just looking into this further, it looks like this is going to be a pretty major stumbling block for using Speckle with compute:
Grasshopper Best Practices for Rhino Compute? (discussion) - Rhino Developer / compute.rhino3d - McNeel Forum
So that affects the coverters and the connector itself, looks like there’s references to RhinoDoc.ActiveDoc all through the codebase. Based on the warning at the top of the API docs ( RhinoDoc.ActiveDoc Property (rhino3d.com)) you’ll also see this causing issues on Mac in the future.
Bummer! Thanks for finding this Chris, since we use the ActiveDoc mostly to get the document units I think we could provide some sort of fallback method. Or maybe there’s a better way to get units inside of a Compute environment?
Hey Matteo, so I’ll post my findings below so others can follow what I’ve done - everythings quite hacky so won’t be doing a pull request any time soon - others feel free to take this and run with it or learn from it: Changes to ConverterRhinoGhShared to reduce calls to RhinoDoc.ActiveD… · secretlyagoblin/speckle-sharp@a5d25fd (github.com)
I actually got the above working on Rhino Compute - I was able to recieve geometry, add to it, and push to another branch without incident.
The only thing you need to ensure is that there is at least one annotated RH_OUT group to send data back to you or the server will throw an error (I just chucked the speckle commit message in there, as in this case we’re obviously just sending the work elsewhere)
Compute has no Rhino Document, so it is unitless, which also means it has no tolerances, meshing parameters, path, document path, etc. I made a wrapper for some of this information with some baked in defaults, but its all hard coded. Additionally theres some other areas where things like hatches, materials and blocks will either need to not import or require a parallel system for managing that kind of geometry outside of Rhino.
This is enough of a proof of concept for us to move forward with our plans, so I’ll revisit this in a few months - if anyone else wants to have a go at this in the meantime, please be my guest!
thanks for this!! I had a look at your code changes and I must confess I also played around with that idea, but it has some drawbacks that I think we could overcome in a different way.
We’ve had an internal meeting about this and I’ve written down an outline of what we’re thinking of doing. You can find the notes here Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. along with some of my own thoughts on the issue.
We’ll be happy to discuss if you see any drawbacks we don’t!
Hey @AlanRynne, read over your notes and that all sounds like the correct way to go - ensuring there is always a doc, rather than throwing in a bunch of edge cases if there isn’t, is a much more elegant solution to that problem.
The only thing I can think of as a wrinkle is ensuring you could set up different templates for different streams, but that is probably an environment thing that could be managed in any number of ways on the compute server, outside of speckle.
Glad I can help, please keep me in the loop if theres any testing that can be done!
I think I added it somewhere in the list, but it may have also been a bit cryptic.
Since this is all theoretical at this point, our initial idea for this “wrinkle” was to check that this could be automated or semi-automated with a short script in your GH/Rhino file.
Still not sure about the specifics on this though. In GH, you could have a script overwrite the default template or straight up modify the “global doc” we are creating by loading a provided one instead.
In a more pure Rhino.Compute setting (with no Grasshopper), I’m not sure yet, but would welcome more feedback/suggestions on this as we go along.
As you say, there’s many ways to handle this outside of Speckle, as long as we provide enough flexibility on our side of things.
We’ll keep this thread updated with any progress!