Node based solvers like Grasshopper lend themselves really well for a multi-threaded approach, assuming you start at the leftmost component, then start growing new threads whenever a data stream splits. There are two problem with this in Grasshopper (three if you count the nightmare of trying to debug threaded applications):
1) Grasshopper doesn't go from left to right, it goes from right to left. Only those components are expired which are potentially affected by a change, and each component is in charge of collecting the data it needs (thus a component on the right side of the network keeps asking upstream components for data, who in turn ask other upstream components for data and so on and so forth until you've reached the left side of the network). This means that if two components inherit some data from a single source, that source needs all kinds of thread protections build in. It practical terms, it means that a lot of the time threads would be waiting for each other anyway, effectively destroying any performance increase you might otherwise get. 2) Rhino is not multi-threaded, and many of the functions inside the SDK are not even thread-safe. I recently made a test plugin to see how the Contour command could benefit from multithreading, unfortunately the surface-plane intersection code is not thread safe which means the whole thing crashed pretty much immediately, and when it didn't crash the results were all funky. -- David Rutten [email protected] Robert McNeel & Associates On Jan 16, 3:50 pm, damien_alomar <[email protected]> wrote: > Don't worry David, I figured multitheading was a big stretch. Not > that its simple by any means, but multithreading is something that > McNeel in general doesn't want to touch with a ten foot pole. Not that > I blame you guys, but we live in a multithreaded world, and I'm a > multithreaded....:) > > The idea of separating out the rebuilding of cluster solutions sounds > like an awesome idea. That sort of separation sounds like it would be > really be useful with large definitions in terms of managing rebuild > times. All of the other requests you pointed out sound really > interesting, especially being part of the toolbar and having a > "cluster editor". > > -Damien > > On Jan 16, 5:22 am, David Rutten <[email protected]> wrote: > > > Clusters don't add any functionality to Grasshopper, they only make it > > look cleaner since instead of looking at 50 components you're looking > > at a single cluster object. > > But the components are still there (I just don't draw them anymore) > > and I have to jump through a series of exceedingly tight hoops to make > > it work. > > > The implementation I have in mind is that each cluster will become > > it's own ghx file (whether on the disk or only in memory, similar to > > Blocks in Rhino), and as such will truly remove the components from > > the main file. Once a cluster is defined as a stand-alone entity, it > > will be a piece of cake to instance it any number of times. This new > > approach will remove a lot of nasty code from the Grasshopper drawing > > pipeline, mouse event pipeline, file writing/reading pipeline and so > > on and so forth. > > > I'm afraid I'll have to disappoint Damien, when I mentioned > > "algorithmic separation", I wasn't referring to threading at all. It > > just means that all the components inside the cluster would no longer > > be part of the solution-process of the main file. Instead, they would > > run in a separate solution (but in the same thread) whenever something > > needs the output of a cluster. > > > At any rate, I've got a lot of work to do on data-structures before I > > can start with the new cluster code, but it might be a good idea to > > post your wishes early, so I don't have to force new features in after > > the fact. > > > I know of the following requests already: > > - Password protect clusters, so they cannot be opened by anyone else. > > - Be able to name, colour code and order input and output parameters. > > - Be able to set default values for input params. > > - Supply a custom help topic for the cluster. > > - Have a separate editor for Cluster contents, which 'explodes' the > > cluster temporarily into an empty canvas. > > - Save cluster definitions as files so they can be easily re-used and > > shared. > > > -- > > David Rutten > > [email protected] > > Robert McNeel & Associates > > > On Jan 16, 8:07 am, rub <[email protected]> wrote: > > > > so, how's that works? as you can see at big > > > picturehttp://www.designalyze.com/wp-content/uploads/2009/01/grasshoppershot... > > > this cluster makes additional geometry for making a paper model from > > > exploded vertices from triangles. any ideas how to do that with or > > > without clusters? > > > anyway thanks David for explanation! > > > > On Jan 16, 1:57 am, David Rutten <[email protected]> wrote: > > > > > I'd recommend keeping as good 3~4 feet distance between yourself and > > > > clusters. The current implementation is absolutely disgusting and they > > > > are short-listed to be rewritten from scratch. > > > > At the moment, a cluster is nothing more than a visual override for a > > > > bunch of components. There is no instancing, no algorithmic > > > > separation. > > > > > -- > > > > David Rutten > > > > [email protected] > > > > Robert McNeel & Associates > > > > > On Jan 15, 11:48 pm, fraguada <[email protected]> wrote: > > > > > > It looks like a cluster. You can take a couple of components and make > > > > > them into a cluster. The icons are above the GH canvas and look like > > > > > an explosion (that is the unclustering icon, the one next to it is the > > > > > clustering icon). > > > > > > luis > > > > > > On Jan 15, 7:43 pm, rub <[email protected]> wrote: > > > > > > > i was doing designalyze last project and i can't get what is > > > > > > thishttp://grasshopper3d.googlegroups.com/web/Picture%204.png?gda=nFtdmUM...- > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text -
