Hi @DavidRutten
Is it possible that GH is running as a separate application from Rhino and communicates with Rhino via socks or whatever?
Reason for this implementation:
This will allow whenever GH stucks or goes non-responsive users can kill the GH process without killing Rhino.
Sure, run another Rhino instance.
Then just write the code to bridge those.
But be aware that you’ll have to share everything necessary: input data, 3dm model, GH definition. Come up with a whole protocol. Oh wait, I guess that is Rhino Compute. It has Grasshopper endpoints, and you can run that locally too. Or on a different machine…
That’s not the same @nathanletwory.
You don’t need to access the 3d model you need to access the file that’s opened (or the temp file in case of concurrent edition).
GH may be working with the file directly accessing it through Rhino3dmIO instead of taking it from Rhino as a parent process.
A lot of issues will be solved, I think. Not only non-responsiveness but also locking Rhino process. Also having the GH minimized when Rhino is minimized. All that will be fixed if they were only running as separate applications with some kind of link to transfer data specifications of the 3d model (not the 3d model itself)
I think doing GH in a separate process is going to complicate things only, because
is a big topic on its own.
It will complicate things for you (the developers) but it will facilitate the life of the designers significantly
GH cannot run without Rhino. It heavily relies on all the geometry functionality that Rhino provides. So what @nathanletwory said is in fact the only possible solution. Start another Rhino session and communicate with that session. Find some ways to pump data back and forth (there’ll be a significant performance impact here a data needs to be serialised, then transmitted, then deserialised) and that will allow you to not lock up the Rhino you work in.
i.o.w. Rhino Compute using the grasshopper endpoint.
Rhino or RhinoCommon?
And what about hooking GH through Rhino’s → Worksessions. GH accessing data from the child/referenced models?
PS: I fully understand how big of a change that would be, I don’t expect this coming in GH2 but maybe you can consider it for GH3
I still have no clue about RhinoCompute’s integration and running it from local (my PC) or LAN PC.
I’m missing a working step-by-step tutorial to integrate it in non-commercial software (I don’t own AutoCAD I cannot even test it and I used up my trial license with ShipConstructor2020)
That’d be probably for Rhino Inside. I’m talking about Rhino Compute.
Here to set up (look at the end of the page for building the server bit):
https://github.com/mcneel/compute.rhino3d/blob/master/docs/installation.md
Then use Python to access the ReST API provided.
Does this require a WindowsServer OS present?
The last method at least not, I have only a Windows 10 install on this machine.
RhinoCommon is mostly a very thin wrapper which exposes the actual functionality in the C and C++ Rhino, it doesn’t really have much functionality in and of itself.
Given your stated reason for wanting this: “This will allow whenever GH stucks or goes non-responsive users can kill the GH process without killing Rhino.”
it may be you don’t need it any more once GH2 is out. Since solutions run on background threads, a stuck or long-running solution will not block the UI. Although there’s only so many cores on a machine so if you end up in a situation where there’s 23 solutions all running amok and for some reason not cancelling stuff will definitely start to feel sluggish.
There’s also still the issue that an unhandled crash will bring down the entire appdomain.
Any chance we can get a beta of gh2?
Isn’t that solvable with what I am suggesting?
Yes, but at a tremendous performance cost.