Visualization Delay Optimization

Grasshopper ShapeDiver
1

Hi all,

We have been working on a model and we’re trying to optimize the model’s responsiveness in ShapeDiver. During this process we noticed that the model’s computation time is not the main delay factor on the responsiveness, so we’re trying to pin down what is.

The definition does some structural calculations and is quite computation heavy, taking around 1.0s to complete the solution, but ShapeDiver’s model update is taking 5,5s to update, on average. We got the stats on the wait time while calculating this average and its inconsiderable (93ms), ping time between São Paulo and Frankfurt is around 215ms. which leds us to think that the main delay is coming from the rendering, even though we’re just sending some simple meshes and lines (mostly with transformations), and the model size is around 200kb.

We talked to @edsahergom during an Onboarding meeting and he was able to give us some optimization tips such as replacing the old “Legacy Display” components to the “glTF” component and warned us that the rendering pipeline is not dealing well with lines and we should send them as meshes for now.

To test the performance gains of each alteration I actually tried uploading different definitions to Shapediver:
1- replacing the Legacy Display components by the glTF component
2 - replacing all lines by meshes

Unfortunately, in the end we didn’t experience any perceptive performance gain in either of them.
As a last test, I uploaded a model where I don’t send any line geometry at all – this speeds things up around 0.8sec (20% of the 4sec delay we are experiencing between the total computation time and the screen updating).
So even if we didn’t send any lines we still have around 3sec of visualization delay - which still seems a bit much for the amount and complexity of our geometry.

We were instructed to post the issue here to let the visualization dev. team know about it. Can anyone think what else could we be missing?

Model link: ShapeDiver
Example stats screenshot:

SD_Stats
SD_Stats257×702 18.7 KB
SD_Stats_Model
SD_Stats_Model640×647 22.6 KB

2

Regarding the model you linked above, my experience is that the computation table reports computations under 1.5 seconds, and on my side the total delay is regularly about 3 seconds (meaning 1.5 seconds additionally to the computation). This additional delay can be explained by multiple factors:

  1. Network transfers (send computation request, download results)
  2. Processing (unpacking) the downloaded results (glbs)
  3. Rendering one frame

While (2) and (3) should result in sensibly the same experience for both our sides, (1) is likely longer on your side since you are using European servers.

We are working on a new performance analysis tools which should help break down the different steps and how much time they are taking in more precision. It would be a good use case to check where time is spent for your model’s computations. We will get back to you once this tool is available.

1 Like