Thanks to everyone who jumped in here to respond. I have a bit to add…
Dynamo did not begin as a project to make “spaghetti” buildings, although I’m exceedingly happy if we help to make more of this type of building possible. I think that, in general, architects, engineers, and contractors produce boring buildings, let’s refer to them as “shiny boxes”, because their tools don’t make it easy enough, fast enough, or cost effective enough to produce anything more interesting. It so happens that Dynamo started while I was working on a “spaghetti” building, but the problems of building “spaghetti” buildings are, at their lowest level, problems whose solutions apply to “shiny boxes” as well. I hope that Dynamo can act as a platform to research and design solutions to building problems for the “spaghetti” which could then be passed down to the “shiny boxes”, in the same way that technology developed for going to Mars ends up in your kids’ toys. But I won’t get ahead of myself.
Most people won’t believe it when I say this, but I don’t really think about Dynamo and Grasshopper or GC in a feature comparison sort of way. But, it’s worthwhile to look at this problem the way that the original poster did, as someone getting started in computational design or design automation and trying to figure out what’s the difference between these applications.
On the level of geometry, which is the likely first target for comparison, the aims of Dynamo, Grasshopper, and GC are similar. They all aim to allow users to create complex geometries computationally without having to write code. As it turns out, a visual programming language is a relatively user friendly and compact, although not perfect, way to do this. So they have that in common as well. The Dynamo project owes a lot to Grasshopper and Generative Components because those applications basically made having the ability to make certain types of curves and surfaces a requirement for any application that wanted to play in this space. Dynamo started its life using the Revit geometry library which was woefully under-powered for the type of geometry that our users wanted to create. In defense of Revit, the limited nature of the geometry functions available through the Revit API makes total sense when you consider that any geometry created using those methods has to be compatible with other Revit operations. It just wasn’t enough for what Dynamo users wanted to do, and for what users crossing over from Grasshopper or GC expected, so we made a huge effort to create a geometry library which could run with the best in this space.
Several users who haved responded to this thread have honed in on one of the things Dynamo offers which separates it from applications like Grasshopper and GC. Through its integration with Revit, we like to say that Dynamo enables you to choose where you want to put your intelligence. For example, you might have an Adaptive Component family in Revit that has incredibly complex internal relationships that you’ve constructed and refined over many months or years. This family has a large amount of embedded intelligence. But, it has limited situational intelligence. That is, you place it next to another version of itself in a project and the two instances can’t talk to each other, and they can’t respond in any variable way to other drivers in the project. This is where you can add an additional layer of intelligence with Dynamo, using Dynamo to get parameters from one to set parameters on the other, or to set parameters on the instances based on some other value in the project. By comparison to GC or Grasshopper, you’d have to build all of this functionality in the graph, which is totally possible, albeit a bit unwieldy. On a more prosaic level, Dynamo solves the problem that making your geometry in an application that is not Revit, when Revit is where you are building the final deliverable, is a pain in the ass.
Finally, I’d like to say to those of you who posted negative Twitter comments about this thread… That is totally uncool. Core to the Dynamo experience is the ability for the “spaghetti” guys and the “shiny box” guys to share their tools to a mutual benefit. This sharing is predicated on open and educational discourse. The next time anyone considers polluting the Dynamo community with negative energy they should consider that at one time they too were seeking answers.
I highlighted ones that you could try to make an argument that deal somewhat with form rather than data. It would still be a tough argument to make. Anyways, here it is:
