ShapeDiver model inconsistent behavior - again

Hi, I am experiencing another inconsistency in one of my shapeDiver models, which I am not able to explain.

Note: every time I refer to 'geometry input’ in this post, I am referring to a .dxf curve which has been generated within a ShapeDiver model, via ‘ShapeDiverExportDownload’ component.

Here is the details:

  1. One of my models is failing to upload a ‘geometry input’.
  2. When check out my GH definition, I find my input curve to be ‘invalid’.
  3. I generate a ‘new geometry input’ identical to the first one, and this one works. See the following image:

  1. I try to replicate the error in a ShapeDiver model uploading the following definition and -surprise- both curves import without any problem on the server. Locally on my machine, one of the two still fails (see screenshot)

Minimal SH model link: https://app.shapediver.com/m/bug-07-10-21-1
GH minimal definition: SH_bug_07_10_21.gh (3.3 KB)
input geometry used: inputCurve_OK.dxf (385.5 KB) inputCurve_notOK.dxf (381.0 KB)

  1. Note that altough it works in the minimal model, ‘inputCurve_notOK.dxf’ still fails to import in my original shapediver model, which is the following: ShapeDiver - Online Parametric 3D Configurator

Honestly, this is getting very frustrating for a number of reason:

1- It costs a lot of time trying to trouble shoot the problem, and explain it to you.
2- It is not something that my customers will understand or accept (and rightly so)

I really hope this time you can provide an explanation of what is not working and why.

Cheers
Matteo

Our apologies for the issues you are facing regarding importing and exporting files from ShapeDiver.

This is a tricky topic that could be the consequence of one or several of the following points:

  • First of all, note that the ShapeDiver shared servers currently run Rhino 6. It seems that you are locally testing files using Rhino 7 and even uploading them to ShapeDiver using this latter version, which might result in incompatibilities.
  • In Rhino 6, there is no headless way to import files, therefore we had to develop our own importer which might behave somewhat differently than the Rhino 7 “Import 3DM” component.
  • That being said, this would not explain why you get different files exported from the ShapeDiver servers with the exact same set of parameters. This can be the result of two things: different tolerance settings (or possibly export options) on different server instances, which can always happen, or an inconsistent way to produce the curves that are used for exporting in your definition. In the last case, I would need to see the full definition to be able to help.

Hopefully we can get to the bottom of this. However, be aware that the new ShapeDiver plugin will rely on the headless importers of Rhino 7, and the exporters will allow to define fixed export options before exporting files, which leads to more consistent results. As an example, I tested the import of both files in our new plugin and both importing operations worked as expected. In that case, switching to the new plugin would fix your issues.

Hi Mathieu,
thanks for the quick response.

As for uploading my models in Rhino 7, it was discussed before and I believe my models run from a server that have Rhino 7 installed?

So, if I understood correctly: looks like a ‘combination’ of problems. I.e. import component failing sometimes, because of ‘some inconsistency’ in how the import file are generated/exported.

A few questions:

  • Is there a way I can set my model so that I have the same tolerance setting for all server instances?
  • “incosistent way to produce the curve” - do you mean issues like the one explained here:

If so, I checked for it and it should not be the case (of course I may have missed it, if you had time to double check it that would be great).

This is the model that produced the inconsistent curve is this one:

The incostintency showed up (ony once) with this input: testInput.dxf (400.1 KB)

It is articulated, and the output curve is generated differently depending on parameters.
The inconsistency happens when the curve is generated through Clipper Offset Component > Extend Curves > Connect Curves .

Finally, nice to know the new pluginwill be more consistent and may fix this issue. I am really looking forward to it, for a bunch of other reasons too!

Cheers
Matteo

I will try to find time and look at your model for some unsafe behaviour regarding the curve generation.

Regarding the possible tolerance issue, you can use the “Tolerance Settings” component of the ShapeDiver plugin to force specific tolerances on the ShapeDiver servers. There is a slight issue with this component: make sure to define values by right-clicking on the inputs and selecting the “Set Number” option of the context menu. Connecting other components will not work.

1 Like