I am wondering if there are any known limitations to the capabilities of rhino compute compared to the desktop version of rhino. I have a script that when I’m running locally I don’t get any error messages or warnings, but when I run it on compute it does not give all the same output. I have tried to limit the use if 3rd party libraries but I’m still using 3 or 4, including my own, self-written one. When I debug by own code attached to the local compute instance I get errors that does not show up when I attach a debugger to the desktop version of rhino.
One of these errors is a null error that only comes up on compute. Because of this my conclusion is that there must be something that is not entirely the same in compute and desktop rhino. How does for instance tolerances get set in compute? Could that be what is causing this problem or do you have other suggestions?
I think you need to be specific and share an example of code and steps to reproduce that runs differently.
You description alone is not enough to give a useful answer I think.
Willem is correct; I can only guess if I don’t have a sample. Tolerances can be different, but without understanding exactly what you are seeing it is hard to say if this is the problem.
Thank you for your answers. I understand that it is hard to do educated guesses without having the script in question to actually try it. The reason I didn’t upload it was that we’re using our own modules so I didn’t know how to include the .dlls.
Anyway, we managed to resolve the problem and it was the tolerances that was the problem like we expected. In one place in the code we used an legacy version of Curve.Join() without the tolerance parameter and it made it crash on compute.
I think, since grasshopper is using the same tolerance as the active Rhino document that it is attached to by default, it worked when we ran it on desktop but not on compute. Now when we realized this it will be much easier to debug in the future as well.
One more question that just came to my mind was if it is possible to set the “document properties” when working with compute. Something like “environment variables” or such for Rhino that decides how Rhino deals with tolerances, units and that kind of stuff?
Please let us know when you run across issues like this. We can tune up this functions to work when there is no document.
Currently, GH uses a fixed tolerance when no document is available. We could make this a value that you can set and pass to compute. I added this to the issue list at
thanks a lot for taking the time and adding an issue for this. I think that it can actually bring some value to others too so it should be implemented. We will keep you updated on things like this if we run into something similar in the future.
this was a while back so I don’t have it fresh in my mind, but I can probably point you in the right direction. If you look at the rhinocommon documentation for the curve.join() method, there is an implementation that does not take it the tolerance, just curve.
I think this is a legacy method that cannot be used anymore with rhino7 (not sure about this part), and it probably uses the documents distance tolerance as the tolerance. This becomes a problem when running on compute because you don’t select the units that the document is using.
I solved the problem just by updating the version of rhinocommon in my toolkit and switching to the version of the method with the tolerance argument.
just to clarify, the original post was not because the code broke, just that I wanted to know if there’s a way of setting global variables for rhino (like a .env) when there’s no active document. It’s not really a problem, just sloppy code from my part since the method without tolerance even gives a warning I think. Anyway, thanks for taking the time to look into this.