Teamworking with grasshopper

I'm pretty new to grasshopper, so forgive me if I'm missing something fundamental.

Does anyone have any good strategies or workflow pipelines for using grasshopper in teams where there are multiple people contributing components to a larger model?

To give it a simple example, what would the best workflow for someone to build a wheels component, someone else to make a whole car component and another person to work on the engine?

My current solution is pretty clunky. It's just to group the important bits, maintain common inputs and outputs and then when it comes to replacing it with a new and upgraded version, delete the contents of the 'black box' and replace it all.

I suppose this is two questions in one: one about team working (referencing etc.), and one about encapsulation.

I'm not looking for THE answer, just for some opinions on possible answers. How do you manage this situation?

Replies to This Discussion

Permalink Reply by Daniel Davis on May 1, 2012 at 10:24pm

Hey Ben,

In my experience, working on a single Grasshopper model is pretty hopeless in a team environment. Normally we end up making individual models that share common geometry (or potentially excel data). I think there are a few reasons for this:

- It is generally really difficult to understand what another person’s Grasshopper definition does, especially if they are still making it. So if you are sharing a definition, then inevitably a situation arises where one person becomes the owner of the definition and the rest no longer understand.

- If you are working on a model complex enough to require a team of people, then the model is probably too complicated for Grasshopper solve in one shot. So in your car example, if you are modelling the wheels to with enough detail to warrant a special wheel modeller, then you are probably not going to be able to run the wheel and engine model in the same definition without Grasshopper slowing down significantly (and there probably isn't much to be gained from doing so).

The method that has worked in the projects I have been involved in is to have everyone working on a separate model that shares common geometry. So in the car example, someone makes the body, and that output the axle for the person making the wheels. Then when you are ready to integrate the model, the person making the car bakes the body, and the person making the wheels picks up the line for the axle, links it to their definition, and bakes the wheel.

It sounds clunky, and un-parametric, but in reality there are very few times you need to see the model all together in full detail. Having everything separated makes it easier to make local changes (you could even swap out the part that makes the car body, and create it with totally different software provided the new method creates the geometry expected by the wheels and engine).

That tends to work for us but I am interested in hearing how other people use Grasshopper in team situations.

Daniel

RSS