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. (https://github.com/RESThopper/resthopper.compute)
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.
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Curve_Extend_1.htm
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Curve_Offset.htm
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