Thu Dec 01, 2016 2:51 am
"in a few years time" that its sound to me a recognition to be one step beyond de competition.
Grasshopper is very powerful, and nowadays much capable than Dynamo with wider and better quality plugins than dynamo. Is, without doubt, the more mature and widely used graphical algorithmic tool in the industry of AEC and its academic side.
I think in Kangaroo, Galapagos, human UI, Honeybee and Ladybug are basic design tools for so much design studios and engineers, or researchers. Grasshopper and rhino also have been the last years a well beloved enviroment platform for a plethora of PHDs related with geometrical problems, mostly because the open nature of mcneel, his apis exposed in .net, c# and python, much accesibles for designers than c++, etc
Ironically, there are, nowadays a plethora of connection tools between revit and Gh (hummingbird, rhynamo,Lyrebird, nudibranch...) and they are capable of do pretty much the same things that GH-ACH connection tool is capable of.
Now, we have to take into account, that those connection tools were developed, in some cases, by people working in their spare time, or at least without receiving a payment for that job. Instead, Graphisoft, i assume, have people working in that connection tool project, so would spect something different from those kind of connections between GH and REVIT, i mean, something different, a more intimate connection between two systems, exactly what Dynamo has achieved with Revit.
We need to be able to create and manage attributes from GH, to have full control of GDL objects (arrays missing) from GH, to access to schedule information from GH, or still much better, be able to generate them directly in Grasshopper, what it would be a super powerful scheduling system, with all the capabilities of managing data via scripts, etc..
We also need to have access to ACH attributes (layers, stories, pensets, surfaces, etc..) via list, choosing and managing all together, but instead the current implementation consider only the possibility to choose them one by one, that is super anti-grasshopperistic. "grasshopperistic" is a important concept i have heard to Andrew Heumman, a super talented designer and grasshopper tool developer, author of Human and Human UI. Its not an easy concept to explain, you need to be a grasshopper user for this, but hey, in grasshopper, you shouldnt open a super long list of element to just pick one of them. I should have the possibilitie to choose all of them at once. For what? i dont know, but that is the way of tooling, of hacking, i need possibilities to then be creative with those possibilities.
I have been both Archicad and GH for years, for me the the connection between the two programs was one of the most exciting things in AEC software panorama of last years, the expectation, i admit, was hi, but now i´am living it like a bluff. The feeling is like, uff, they are not getting the point...
In my opinion, it is very important that graphisoft need to understand well the benefits of computational design is bringing to us designers.
I guess, its no so much in the designing and geometry generation part of the problem, but in the ability of creating and managing data computationally. And I say Data, i mean not only the schedule values of a project, "data creation and management" should be also aplicable to Attributes, Layers, Stories, project information, views, layouts, autotexts, etc, etc, etc... then, we will be talking about real computation design, with real tooling capabilities. "Tooling" is other super important concept to me to take into account.
Dont missunderstand my words, i would like to be constructive and no be merely critic. Archicad is the bim software i know the best, is my working tool for every day and i love it. But, we have to admint, there is still so much work to do with this GH connection thing... And we are late already...
please, neither consider my as an arrogant, i respect the work of graphisoft. Just hope that all this disordered ideas could serve for something to the Connection Tool developers.