Issue with Rhino Inside and its compatibility with Rhino Common API


I have an issue with Rhino Inside which currently does not read/work some RhinoCommon APIs.

The python script that calls RhinoCommon API such as “geo.Brep.CreateFromSweep” is working well in Grasshopper on my local computer. But when it is passed to Rhino Inside, the system does not yield what the API supposed to give as an output. For example, the output of geo.Brep.CreateFromSweep method is null through Rhino Inside, while it is perfectly fine in Grasshopper environment.

I already saw this kind of errors with other RhinoCommon APIs such as Geometry. Curve.Offset Method and Curve.Extend Method.

Could someone from McNeel check this issue, please? At the moment, I am creating my own version of offset method by employing other APIs, so that the output result is exactly the same as what Geometry. Curve.Offset Method gives.

It will be much appreciated if one can answer or give some advice regarding this matter.



@stevebaer @bobmcneel

Hi @jchun726,

What application are you running Rhino inside of?

Can you post a Grasshopper solution that works correctly in the Rhino WIP but does not work correctly when Rhino is running inside some other application?

– Dale

Hi Dale

Thank you very much for your reply.

Our team is not running “Rhino Inside” with other application.

We are developing a backend server with Rhino Inside integrated after reviewing Resthopper development, a hackathon project developed last year. (

We found that some C# APIs such as Curve_Offset and Curve_Extend gives null data, when they are passed to Rhino Inside. Therefore, I had to make some customised methods using other APIs, to find an alternative way to mimic the problematic methods.

Recently, I found that “Intersection.BrepBrep Method” causes a similar problem. With some cases, the method yields what it is supposed to give as an output parameter, but sometimes it does not.

I was going to ask McNeel to review the code where it causes the problem, so I prepared for the file in which the inputs were internalized in input parameter components inside Grasshopper.

An odd thing is that all of sudden, when we test the file where input parameters were internalized with data, Rhino Inside gives the expected output result. However, the the normal grasshopper file where we dynamically pass the inputs (the same data that we internalised in the components) through our server gives null data, as Rhino Inside does not read “Intersection.BrepBrep Method”.

We are currently developing the web application with back-end geometry server running Resthopper system integrated with Rhino Inside, and the code that my team developed so far is more than 5000 lines long. I don’t know whether sending our geometry computing codes to McNeel is necessary.

It will be much appreciated if you can give some advice regarding this urgent matter. I am also happy to discuss this issue with McNeel through Skype if necessary.

Once again, thank you!

@dale @bobmcneel @stevebaer

Hi @jchun726,

I’ve changed the cateegory of your post some it gets some attention from those working on Rhino.Compute.

– Dale

We are finding some issues in our geometry functions where the code is trying to get a something like a tolerance from a document. Since no document actually exists, the function bails out. We recently found this with our curve offset function and fixed the issue. This may be the problem with the functions you are calling. I’ll see if I can repeat the problem.

Thanks Steve. @stevebaer

Could you please tell me when the update will be released?

_ John

The offset fix is already in the current WIP


We are currently facing another problem which is caused from Rhino Inside after the recent WIP update.

Could you please tell me where I can find the update log for WIP? The link provided from Download page is broken.

What is the problem?

1 Like


What is the tolerance value that Rhino Inside, then, reads if I do not provide as an input parameter?

I usually have problems with setting up tolerance value for the api where I am required to provide.

At the moment, I put 0.001 for tolerance value - and it is usually fine except some complex geometry operations.

The problematic situation I am currently facing comes from “BrepBrepIntersection” API. The intersecting curve (output) is not on both two Brep faces.


Does it make sense to add the Rhino inside category/tag to this post?

Regards, Wei Pien

Oh, never mind. I read the rest of the thread.