“Dynamo的今世前生”——Dynamo问答(转载&翻译)

原文链接:Q&A about Dynamo

有一回,Marcello Sgambelluri AutodeskMatt JezykZach Kron译注:这两位是Dynamo在市场和产品功能方面的主要负责人逼到角落里,用一大堆关于Dynamo起源和未来方向的问题把他们搞得焦头烂额。我们觉得把这段故事拿出来跟大家分享应该会很有趣。你也可以从Marcello 博客中找到更多好东西。

为什么会想到开发Dynamo?

[Matt] Ian Keough(译注:Dynamo创始人)在纽约的Buro Happold公司工作时,经常需要在RhinoRevit之间交换数据。为了让这一繁琐的工作变得更有效率,他编写了Dynamo。当时的基本想法是:既然Grasshopper可以用参数化,计算生成的方式驱动Rhino中的形体,我们应该完全可以在Revit里做类似的事。

为什么Autodesk会决定投入资源完善Dynamo?

[Matt] 我创建了一个商务案例(Business Case),让一些同事在Dynamo开源项目上工作。这么做的原因是:

  1. 我本人是个技术狂,而且已经花了很多业余时间在Dynamo开发上。
  2. 我看到了让计算式设计(Computational Design)和BIM联系起来的可能性。

现在看来这个方向确实是可行的。市场对“计算式BIM”(Computational BIM)的反响很热烈,并且已经开始有人采纳了。

 

当时想着要把Dynamo做成Grasshopper的竞争对手吗?

[Matt] 我们从没想过要做一个Grasshopper的复制品。确实它们都基于可视化编程的基本理念,都用在AEC领域,试图解决的问题也很类似。不同之处在于,使用Dynamo的方式更加灵活。比如,可以用Dynamo驱动Revit族,可以做递归求解,可以用来弥补各种Revit工作流程的缺失或不便,可以不经过烘焙(Bake)直接生成真正的建筑构件(译注:烘焙是Grasshopper的典型流程)

 

[Zach] 大家都看得出来,DynamoGrasshopper肯定是同一领域的软件产品。很多设计师会把建筑物构思成一个系统性或者规则性的东西。这些软件产品可以让设计师更加直观地创建和修改一个抽象系统,而不必去写一堆API程序代码。Grasshopper的开发者很聪明,很早就意识到了记录建筑形体生成过程的价值。类似的做法在工程界(比如Labview, Mathlab, Simulink等),音乐多媒体界(Dycling74 Max, VVVV等),动画界(Softimage等),其实早就广为运用。我们建筑师有个习惯,就是倾向于采用那些在其它领域已经获得成功的“新技术”。Revit也是在类似的环境中产生的:参数化建模和图纸同步生成技术已经在制造业应用多年,最终传入建筑业,催生了Revit

 

Dynamo也是非常类似的情况,只是出发点与Grasshopper有所不同。Grasshopper基于CADRhino平台,Dynamo基于BIMRevit平台,这意味着两者对建筑构件的亲和度有差别。Dynamo能够像传统CAD软件那样处理纯几何造型,但同时也注重对建筑构件和建筑系统的操纵。类似的,尽管Revit也可以像CAD软件那样通过拉伸操作来生成墙和屋顶,更合适的工作方式其实是使用定位线和草图模式来创建这些建筑构件,因为这样才能建立起相互之间的关联关系,使之成为一个建筑系统。

 

听上去可能有些矛盾,虽然Dynamo最初针对的是一个非常特定的业务流程(生成建筑信息模型),它的内部架构其实是完全独立,不依赖于任何软件平台的。换句话说,Dynamo完全可以作为一个独立工具运行。一方面我们正在努力让DynamoRevit的交互更紧密,另一方面我们也在致力于开发核心功能,使之可以与其它工具很好地结合。第三方开发者已经做出不少原型系统,它们可以让Dynamo运行在机械,动画和结构软件上。

 

最初是怎么聊起Dynamo这个话题的?

[Matt] 里头确实有些有趣的故事。2009ACADIA译注:电脑辅助建筑设计国际研讨会上,Ian给我看了他做的Dynamo。之后他从纽约搬到洛杉矶,加入Vela公司,开发iPad上的三维浏览器。之后他把Dynamo做成了开源项目,并且乐在其中。我记得在洛杉矶跟他一起吃午饭时曾说:如果你把Dynamo开源,我肯定可以想办法拉几个人帮你一块儿做。后来他的确开源了。之后Zach和我一起在AU 2011上讲了一堂Dynamo的课,好像叫“参数化的超级模型(Parametric Supermodels)”。那年春天我们刚好有个实习生加入进来做Dynamo,他重写了底层引擎。同一个春天VelaAutodesk收购。Ian和我在电话里聊起Vela什么时候正式被收购,忽然意识到我俩现在在同一家公司了。之后我们在Dynamo上投入了更多的人,Ian也在2013年一月份全职加入我们团队。现在我们已经拥有一个非常完整的Dynamo开发团队。2013年夏天的时候我们把DesignScriptDynamo团队合二为一,以后Dynamo的底层将使用DesignScript引擎。

 

Revit的集成是后来才想到的吗?一开始Dynamo就是一个独立运行的程序?

[Matt] 一方面,Revit从来都是我们的重点。另一方面,我们也做了不少工作确保Dynamo可以脱离Revit独立运行,并且可以比较容易地被整合到其它软件中。现在Dynamo已经可以与InventorMaya集成。我们还在做更多的集成工作。

 

我明白有很多未来的计划你不方便透露。但还是请谈谈Dynamo的未来吧。

[Zach] 做开源项目很大的一个好处,就是我们完全公开正在做的事情。看看Github上提交的东西,你就能了解我们现在正在做什么了。

 

首先,Dynamo身处一个开放的社区。我们相信我们的用户都非常聪明,我们致力于让他们更加有效地开发或者拓展DynamoDynamo的代码一直会保持开源,供用户下载,编译,修改成更适合他们各自不同需求的版本。现有的内容分享平台(PackageManager)会持续增强,让不同用户可以分享他们的Dynamo结点,脚本,或者编译好的库。

 

我们现在正在继续与BIM做进一步的深度集成。当前Dynamo版本(0.6.3)的工作重点在建筑早期设计阶段。我们在开发这一块功能(主要是一组全面的几何造型工具)的同时,也会继续在广度上与Revit其它功能做集成。

 

我们知道,AEC行业太复杂了,非协作不能成事。也没有哪个工具可以解决所有问题。我们会继续完善与其它工具的交互(比如ExcelArduino),同时提供更多与建筑相关的特定功能(比如日照分析,结构分析等)。

 

Dynamo拥有一个功能全面的计算引擎,可以处理各种通用的计算式设计需求,比如列表处理,数学计算,逻辑,输入输出,数据可视化等。因此Dynamo可以被当作一个独立的计算工具使用,也适用于那些想要在设计流程中作一些轻量级改进/整合的情形。

 

现在Dynamo的核心功能都与Revit有关(从Revit获取信息或者把信息输入Revit),其实同样的功能可以提供给不同的工具。事实上,从程序内部来说,Dynamo只是把Revit相关功能作为一个模块载入进来,类似于Dynamo载入Excel模块并且使用其功能。Dynamo团队中有不少Revit专家,但我们也在与其它领域,使用其它工具的用户和开发人员积极沟通,开发更多功能来解决他们在其它工具中的需求。

 

开源到底意味着什么?

[Matt] 作报告的时候不用担心法律约束(译注:指公司会尽量避免对尚未发布的产品或功能作出任何承诺,以避免可能的法律问题)。喝酒聊天的时候更是如此。

 

[Zach] 开源意味着用户可以搞明白一个程序是如何做到它所提供的功能的。用户可以持续改进这个程序,添加他们想要的功能。用户同时也可以是开发者。

 

为什么你们把所有的用户都看成是开发者?因为他们可以上传自定义结点?

[Matt] Dynamo定制化的门槛非常低。你可以用让自己感觉最舒适的方法去定制Dynamo – 创建自定义结点,写Python脚本,或者写其它语言的脚本,甚至写C#或者C++程序然后编译成库载入到Dynamo。所有这些定制化的内容,都可以在办公室内部通过文件分享,或者在世界范围内通过PackageManager分享。(编译的二进制库文件很快就能在PackageManager里分享了。)