Model taking <1 sec on local PC exceeds 10 sec computation time on ShapeDiver


I have some problems with a definition that on the desktop PC is taking less than 1 second to compute.

Whan I upload it to ShapeDiver, the computation times seem to be much longer, and not very consistent. Sometimes they also exceed the 10 sec limit.

The user id is abiya-mt. The model can be found at

ShapeDiver - Online Parametric 3D Configurator (simplified version)

ShapeDiver - Online Parametric 3D Configurator (original model with texture maps and additional generated data)

I’m making these tests by changing the Length / Width / Height slider values.

I know you usually need some minimal model, but in this case I’m just noticing an overall slow and unconsistent performance, maybe there is something that works fine on the PC but is causing troubles on the platform - and again without any error/warning available troubleshooting these issues takes longer than developing the model itself.

For the future, it would be really helpful to have some report with information on the solution, similar to Metahopper’s Bottleneck Navigator.

Thank you for the support


Thanks for your feedback. ShapeDiver will have better error reporting in the future.

How long does it take to open your definition locally?

Also, I noticed you are using opacity map for the pattern on the pergola. Large textures embedded in your model can also cause problems, more in this post:

Hi Pavol,

Thanks for getting back to me quickly.

The original model takes 2.6 seconds.
The simplified version - which has several features disabled, including the opacity maps - takes a very short time (it’s not even reported in Grasshopper’s status bar) - well under half a second.

I’m testing them on a very standard PC by the way (i7 4770 with 32GB of RAM)

The model is using a single opacity map - a 512px wide png file under 25 KB in size. The texture is then tiled and applied to several simple meshes, which are in turn instantiated using ShapeDiver’s transform scrript. Is this supposed to create problems? Should I just make “physical copies” since the meshes are very simple?

Everything runs correctly on the local PC.

Thanks again for the support

It seems that you did everything right, the texture is really small and it shouldn’t cause any issues. Opacity map is definitely faster than creating real meshes here so don’t change anything in your model.

You probably experienced some performance fluctuations on our servers. While we do our best to minimise them, this might still occur and our dev team will investigate further. Please let me know if your models don’t perform as expected.

Hi Pavol, thanks for checking it.

I can’t check things right now because of a server issue but as soon as this is fixed I will make some tests and get back to you.

@Marco_Traverso I would like to follow up on this one:

I have been doing some testing using this model, and also checked the computation logs (which in a few weeks will also be accessible via our new platform). We keep quite detailed information in these logs, like:

  • how long did the computation take (pure computation time, from setting parameter values until the Grasshopper computation finishes)
  • did the model have to be opened newly (which means extra time for loading the model, which is also recorded), or was the request processed by a worker which already had the model loaded
  • how long did the request have to wait before being processed by a worker
  • how long did it take to save the results of the computation
  • etc

The logs for this model typically show pure computation times between 0.5 - 3 seconds. Opening the model the first time took about 3 seconds. I saw that about 10% of the request took up to around 10 seconds pure computation time (there are about 40 requests logged so far).

As mentioned above, soon you will be able to see this data yourself.

This model fails to open for me currently. This seems to be related to an issue with a texture image used by it, for which the download request times out. Did this model work you previously? I will dig into this.

Thanks for getting back to me on this, @snabela

Great to know about the upcoming logs, they should be helpful in troubleshooting and optimizing the models.

Yes, as I mentioned there is a technical issue with a domain redirect which prevents the textures to be loaded correctly.

I setup the model with textures loaded from a different web server here:

Right now it seems to be working better, I will test it better when the server problem is fixed.

If you have any additional feedback please let me know

Thank you


A quick update about this issue: today I uploaded a slightly different version of the same definition (ShapeDiver - Online Parametric 3D Configurator) and once again I ran into a computation time beyond the 10 seconds limit - on the local computer it still takes less than 1 second.
I setup smaller initial dimensions and disabled some geometric features but it didn’t work.
I also tried the new platform and got the same error.

For me the solution was to avoid the download of an external texture (which is in turn very small) by adding a toggle, which allows to download the texture only after the model is processed for the first time. It 's a bit of a hack, and I wouldn’t expect it to be necessary, but in this case it has worked.

Since it seems the first upload is quite critical, when there is a problem with the processing of external data (either geometry or images) it would be useful if the new report system could actually mention it.



What do you mean by downloading a texture? Are you referencing the url in Grasshopper and using it as the texture input, or are you downloading an image file using the import component and using the Bitmap object as input?