Output on ShapeDiver different from lokal Rhino & Grasshopper

Hi guys

I have problems with the output of a configurator on ShapeDiver. The results have a bug that does not occur when I run the GH script locally. This of course makes it hard for me to understand where the problem is. Does anyone have an idea to fix this?

Here are two images for comparison:


Link to configurator on the platform:
https://www.shapediver.com/app/m/sitzkissen-v2-2-32

Parameter values that occur problems:
sitzkissen-v2-2-32.json (1.7 KB)

Thanks for support :pray:

Hello everyone,

Iโ€™m experiencing a similar error again, this time in a different script. Last time someone from ShapeDiver seemed to have fixed the problem. How can I prevent this bug?


https://www.shapediver.com/app/m/sonnensegel-v2-2-6

Many thanks for help and answers

Which version of Rhino are you using locally? This model is uploaded on the Rhino 8 system, did you try it locally in this version?

Yes, the current Rhino 8 version runs locally

@mathieu1 Are there any hints where I can look for the bug?

I would need an example of the input file you are using with the model, in order to test the issue.

I managed to get an example input file from your online ShapeDiver model. After loading it in my local Grasshopper, I can see the same result as in ShapeDiver:

This likely means that you are performing unsafe operations in your definition (assuming the order of results or assuming the direction of curves after explode, join or split operations for example). This type of operation often leads to different results on systems with different configurations and versions.

I had a look at your definition and could not locate the issue yet. This will likely need some thorough investigation in order to identify the cause.

Have you changed anything in the backend? It works now. How should I deal with this kind of bug in the future?

As I mentioned above, I also got the correct result locally. This is a typical issue when doing operations that are unreliable, even identical versions of Rhino might give different results at times. Nothing changed on the backend but it is likely a case where a different server of the ShapeDiver system gives the same results you experience locally. This does not mean it will keep reliably happening in the future.

I would still suggest to go through your definition and check the type of operations I mentioned above. Is there any point in your definition when you assume the order or direction of objects that come from a specific component? Then you can apply one or the other check to make the definition more robust. Some of these principles were covered in one of our blog articles.

All right, thank you very much for your explanation, I think thatโ€™s clearer now.

One more question: Does the SD server change after a definition has been uploaded? Or can we assume that the expected result will appear if this is the case initially?

There is a set of multiple servers on which your definitions can be computed, so in practice no, you should not expect that the same one will be used for all computations for your model. However, it is correct that for the exact same set of parameters, the model will always return the same result as it is cached after the first computation request.