Upload problems -

I get this error message when I try to upload the gh file. I know I used that plugin, but I deleted them afterwards. Now I have tried to search for the components using a script that I found(https://www.grasshopper3d.com/forum/topics/override-disable-zui-display-on-a-python-component). I can not find the component, what can I do?

Try copying all the components of the definition to a new document, save it in a different file and upload it to the platform. If the problem persists, there must be a component from the plugin left, you could proceed by elimination.

Thanks for the tips. I found the component in a Cluster.

1 Like

I am having problems uploading some models even though they have run on the platform in the past. The computation time is about 3 seconds on my computer and the first opening of the GH script takes about 5 seconds. I have a designer plan, so up to 10 secs should work.

When uploading the following error appears:


An older version that is still on the platform (and cannot be uploaded anymore) is this one:


Does anyone have recommendations on where I should look for the problem?

It seems that due to the geometry which is embedded in the model, the initial loading takes longer than your subscription supports. I suggest you try the following, which should make your model more efficient in general:

  • do not embed default geometry directly in your model
  • upload a file containing the default geometry from the model edit page after model checking
  • save the model, which will also save the default file

This will speed up loading of your model significantly, which means when the model needs to be reloaded on our workers it will load faster.

Please let me know whether this helps.

Thanks for your answer, that makes sense. Unfortunately the same error still occurs. Any hints where I can also look for the bug?

Can too many levels of clusters be the cause?

Many thanks for your feedback Jannek! I will review this today, it will take a bit, I hope for your understanding.

I can recommend the Performance Analyzer that comes with the Pancake plugin (which is excellent for other things as well):

It will tell you which components take the longest.

Kind of. Make sure to not put too many things inside clusters. If a cluster has to be recomputed (so any of the inputs change), it will always recompute the ENTIRE cluster, not just the things inside the cluster which are down-stream from the changed input. Nesting large parts of a definition into clusters can lead to much longer calculation times. Make sure to only use clusters for small functions related to one thing and not combine many separate things in clusters.

Hope that helps.

If it’s the case, the time is used to deserialize embedded data back into geometry, which may not be detectable by current Pancake versions. It happens during opening the Grasshopper file, not during computation while SD measures all.

For the latest Grasshopper version, IIRC the answer is no. Only part of cluster is recalculated.

I suspect that our custom check of the model takes too long. This check inspects the ghx (or gh) file before opening it. I will test this today afternoon and get back to you.

Oh good to know, I thought it was still the case. Either way I find that using Clusters is usually not worth it. It hides logic and makes it harder to understand as a whole. If I have a certain function that I might need again I will turn a cluster into a User Object and then use that. I find this strategy has really improved the readability of our documents, which are a lot of times very large.

@Jannek please try again

Thank you Alexander, now it works.

Great, many thanks for your feedback, and please excuse the inconvenience.

Not a big deal. I also have some problems with the display in the SD Cloud: more complex SubDs cannot be displayed, neither with the SD Display nor with the GH Preview. Does anyone have an idea how to fix this?

Could you please share a minimal definition that shows this issue?

Sure. I just tried to upload a minimal version to SD and got the following error:

Saving the SubD as a Rhino file requires about 3 GB. The minimal version (with internalized geometry) was the one:
SD_SubD_display.gh (524.3 KB)

…sorry, I meant about 3 MB.

SubD objects need to be converted to meshes for use on the ShapeDiver platform. If you send SubD objects to display components, our plugin automatically does this conversion. At the moment, this conversion is done with a density of 3 (this is identical to the conversion done with the “Mesh from SubD” component of Grasshopper), which leads to a mesh with a half million vertices.
We will review if we can by default do the conversion with a lower density, which would result in smaller meshes. However, you can alway do the conversion yourself in your definition using “Mesh from SubD” and as a consequence control the level of detail of display meshes in the ShapeDiver viewer. In any case, keep in mind that the mesh used for representation will always be far heavier than the SubD representation.

Many thanks for the explanation :pray: