Hi Riccardo. You have a lot of questions. Let me see if I can answer them, but if I miss some, please let me know. First, you mention that you want the solution computation time to be fast, but that billing is also an issue and you want the service to shut down when not needed. Those two things are a bit in opposition to one another. Let me see if I can explain how the Rhino.Compute startup/shut down process works.
Rhino.Compute has two different processes (ie. executable files). The top layer is called Rhino.Compute.exe and this is a simple process that primarily stays up all the time listening for incoming HTTP requests. Note, you are not billed (by McNeel) when the Rhino.Compute.exe is running. If it receives one, it handles authentication via an API key. If the request is valid, then it handles spinning up one or more child processes called Compute.Geometry.exe. When the Compute.Geometry.exe processes start, that’s when you start getting billed by us using the core-hour billing formula. The startup time can take a bit of time because it’s having to launch Rhino and Grasshopper and load any other plugins you might have… plus you might be starting 2, 3, or 4 of these instances so it can take a bit of time to start up. But once these child processes are running, each time a request is received, it’s passed along to the child to process and the solution is started. There’s no way to “preload” a GH definition, but whenever you send a new GH definition via Hops to Rhino.Compute, that definition is stored in memory and an ID is sent back to Hops as part of the response. Then when you send different values from Hops for a different solution, then it just has to pass along the ID for the original definition (instead of the actual definition each time) and then Rhino.Compute will just go and find that definition and load the values and perform the solve.
Now, let’s say you’re done using the Rhino.Compute service. If it’s been 1 hour (the default), the child processes will send a request back to the parent layer to see how much time has elapsed since it last received a valid request. It sends back a time span value and if that is longer than the idle span time that’s been registered with the child process, then it will handle shutting itself down. Now the default idle span value is 1 hour, but you can configure that to be whatever you want. It could be 2 minutes (if you really wanted to shut things down right after each request), or you could set it to be something extremely long if you wanted to keep the service running indefinitely. Now, there are a couple of things to keep in mind. Each time you shut the child process down, you’re going to lose the “cache” that has been built up by Rhino.Compute. That includes the cache that stores all of the results. You see, Rhino.Compute stores the input values and the results on each solution. If it detects the same inputs that it has already solved, then it will just return the solution for that and bypass performing the full computation. This potentially can save you a lot of time… and you could even script this setup ahead of time if you wanted all of the permutations to be pre-computed. Then, when a user asks for a given input state, the response time should be very fast. However, if you shut down the child processes, then that cache gets erased. The second thing to consider is the startup time when you want to solve a solution the next time. As I stated above, the startup time can take some time because it’s starting up Rhino and GH in the background. So, while setting a short idle span value might save you some core-hour billing time, you might incur some time delays when the next user sends a request and has to wait for the child processes to get spun back up.
As for your question about writing out bitmaps… You have to remember that in Rhino.Compute there is no document or viewport. You can tell it to instantiate a new Rhino document each time a request is received, but there’s no really viewport (it’s a headless document). So, right now, taking screenshots of a viewport is not possible. You could potentially try to script a rendering to start and write the bitmap to a byte array and send that back to your front end… but I haven’t really tested that and it would take some decent scripting chops to pull off. As for your GPU requirement, I think that would be up to you and whatever VM service you contracted with. I don’t think Rhino.Compute has any sort of GPU requirement, so I don’t think there would be anything from our end that would effect that.
Lastly, my recommendation would be to start small and local. What I mean is, start by testing out Hops. When you install Hops, a new instance of Rhino.Compute will get started automatically each time you start Grasshopper. You can build out your workflow by testing Hops locally and there’s no costs when you testing things locally. Once you have your workflow tested and working locally, then you could setup a VM and point Hops to send your definitions to the VM instead of your local instance. That’s just my suggestions.
Here are some links to help you get more familiar:
