GH is completely biased in a node-to-node approach. All right, I love it. But opening it to a process-to-process approach would be breaking the ceiling. And doing so in parallel makes it an ideal platform for experimenting with AI.
For a developer, the fundamental class now is the GH_Component, but the ideal should be something like GH_Graph or GH_Definition, where a document contains them inside, and it contains the components (which can be handled parametricaly from code at least) and where the solution occurs. Being able to categorize the processes as objects themselves in a native way seems to me to be the natural step that GH2 should aspire to. It allows, for example, to plug a process (a circuit of components) as an input into a component (the process with input and output restrictions, like data type or data structure), making GH more OOP.
Think of Kangaroo, you can only define the initial process and adjust the parameters on the fly, but if you could define the processes parametrically (like a decision tree) while running it? Then GH would be ideal for AI. Although not the most efficient approach, it is the most powerful. And I prefer that because I rarely work with huge amounts of data. My bottlenecks are boolean operations and that’s in other hands.
Mmmm…I ilke this idea of slave workstations, it could make some definitions “usable” that nowadays are just barely “loadable” (more than 5min on solution time). It could be a nice way to be able to open heavy desfinitions in meetings with a tiny laptop that calls the office workstation for the hard work or use the inactive workstations at the office to perform calculations and gets back the preview representation. I can imagine a way of doing this in GH1 with the new data export components, but not without a little bit of tinkering.
Dani proposal is interesting too. I like the idea of components/complete-solutions been a data type in GH. It could open a lot of interesting gates (even related to RIL idea).
Well duh There’s no arguing over facts like that. Your comments are absolutely correct.
I was a little scared that my comment was going to be misinterpreted. I can understand a desire to have multiple solutions running and that can already be achieved with multiple copies of Rhino/GH running. Of course the total solution time isn’t going to be done faster, but that may be fine because your background process is going to get less computation time allocated to it from the operating system. The same goes for every other process running on that computer (Chrome, music player, drop box sync,…).
One of the nice features of async that hasn’t been mentioned here is the possibility of maintaining a responsive UI while a solution is being computed. This would mean GH could choose to either wait for a solution to complete when the user adjusts a slider value or it could immediately trigger a new solution while at the same time cancel the existing solution. Partial results could also be displayed as components are solved.
I think this is exactly where i started from. Didn’t say it explicitly , but it is for sure my biggest concern. I always feel annoyed doing various hacks with speckle in order to be able to have fluid ui and streamlined async comms with the server.
There’s no arguing over facts like that. Your comments are absolutely correct.