Hello,
We are in the process of optimising our computation within the grasshopper definitions and wondered if it was possible to use some sort of save state into one definition, or if we should use multiple definitions using many sessions.
Say our definition is about 15 seconds to fully compute but could be done in 5 separate steps using different states, what would be our best course of action to optimise computation time and credit usage?
Thank you!
I’ve created a few boolean toggles to help optimize the script runtime as well. Wasn’t able to see on their system what the benchmark runtime is, but seemed to improve slightly. What is your benchmark between some of your functions? Do you have a sample script that can be shared?
Try setting toggles between the different functions and see how shapediver reacts
Also they have this video. Could be a data tree issue in your case
You will not be able to save partial states of the upstream components between different computations. It is likely that when you send a new computation request, the definition gets picked up by a completely different server which cannot access the previous states.
That being said, the solution suggested by JakeZ usually works for ShapeDiver users. You can define toggles to switch on or off computationally intensive parts of your definition, if they don’t always need to be recomputed. This is typically used when the algorithm should build and export production files for example: those parts should be disabled during the configuration process and only turned on right before the export should happen.
In general, if your definition takes 15 seconds currently, I would explore the possibility to optimize it and make it run faster before splitting it in several definitions. Ultimately, you can do that in order to make sure you never hit the computation limit, but at the moment several ShapeDiver models can only be connected together using the API. I would use this approach as a last resort. Note also that you are able to upgrade your account to get more computation time (up to 30 seconds on shared systems).
Thank you JakeZ and Mathieu for you responses,
We in fact went with the boolean toggle implementation and found this video which was very informative as well and it works fine for our case. It would indeed work better if we had a lower polygon version to toggle to.
Correct me if I’m wrong, but with that information, I should also assume that every change made to a parameter would trigger, regardless of the session of an embedded viewer, a request to your servers and that every component in the grasshopper model would be recalculated. Toggling on and off booleans in the grasshopper model would not work if a step of our model requires information from a previous section that has been toggled off. This works locally because running grasshopper on our computer saves the component values, but that memory is released once the computation are done on your end, so that wouldn’t work on shapediver.
Mathieu, you also mentionned connecting several models through the API, would I be correct to assume that it would only be possible through the backend API?
Thanks again!
As Edwin explains it in the webinar you linked above, you can always toggle downstream parts of the definition that contain operations you do not need during the configuration process, such as creating detailed export files. However, you are correct to assume that disabling upstream parts of the definition will never work, as servers will not be able to recall the solution of upstream components before executing the rest of the definition.
You can also use the viewer API to connect several models. It is very simple with the version 3 of the viewer to open sessions to several ShapeDiver models in the same viewer, at the same time or one after the other, and to send results from one model to the next. I will attempt to create a simple code example to show how that can be done, but we already have an example to show how to open sessions to multiple models at the same time: multiple sessions - CodeSandbox