Are there any best practices or documentations for increasing the speed for the transfer of data between these two? specially for meshes, mesh w colors, texts, etc.
Unfortunately, I don’t think there’s a whole that can be done to reduce the package size short of reducing the mesh size, etc. But, probably your best bet is to look into caching. It’s possible that you could run a script that would automatically generate all of the results from a list of inputs, where the results are stored in the cache on the server. Once the results are stored, the next time you send a request with the same parameters, the server will respond with the immediate results without having to redo the calculations (which ideally should improve the speed quite a bit). The one downside at the moment is that the cache is currently stored in memory… which means once the child process is shut down (after the idlespan time limit is reached) then those cached results will be removed. A temporary fix would be to store the results in your own CDN… but it’s on our todo list to move caching out of the compute.geometry project and up into the rhino.compute project. From there, we’d like to work out a persistent data storage (possibly a redis database) which would store the results more permanently there. I hope this helps.
You could play with compressing the meshes using draco compression to minimize the data size being transferred. RhinoCommon and rhino3dm.js both have support for draco compression. This might help.
Thank you both! Draco compression seems to be a good solution I will look into it!
Hi @AndyPayne, do you think it would be possible to request for a (or few) specific output from Grasshopper to client side, rather than receiving all the outputs each time we modify the parameters?
This may be helpful in scenarios where base geometry could stay the same, but colours, or translation parameters change. or only one object within a scene would change…
Hmm… It’s possible, but it might cause more confusion for most people. Instead, could you break out your definition into two sub-definitions for Hops where you could control which outputs you wanted in each file?