基于形状文法的建筑生成系统计算框架研究

宋 安

(西南交通大学建筑与设计学院，四川 成都 611730)

1 概述

形状文法诞生于20世纪70年代[1]，它在本质上类似于一种符号重写系统，但计算过程中的执行对象不是零维且离散的“符号”，而是多维且连续的“形状”。在表现上，形状规则是它的主体，由“左形状(LHS)→右形状(RHS)”形式构成，表示从一个初始形状中找到LHS，并替换为RHS。它的规则简单易懂，但却能利用“形状”的特殊性质构成相对复杂的设计[2](见图1)。形状文法既能够作为一种独立的形式化分析和设计工具，生成具备风格一致性或创意性的设计，也能集成在一个复杂设计系统中，用于前期的概念推敲或后期的模型生成，并被广泛应用于建筑、艺术、工业等领域。

但令人遗憾的是，该方法大多活跃于学术界而鲜少被应用于真实的建筑设计活动中。究其原因有二：其一在于缺乏足够健壮的形状文法解释器，使其难以充分在CAD环境中发挥全部潜力；再者，形状文法本身仅仅具备形状生成的能力而缺乏评估和探索等机制，而设计探索阶段是建筑师思维过程中的重要一环[3]，通常很难依靠固定的规则来生成适应复杂环境的建筑方案。

解释器的开发一般涉及形状在计算机中的数据表征形式与形状识别算法的开发，通常依赖于专业程序员的努力。建筑师则可通过设计一个更为完整的算法框架，将形状文法嵌入其中并与其他方法模块相互配合，完善其生成、评估、探索设计的能力。而后者则是本文将要讨论的问题，借此机会提出了一个以形状文法为核心的建筑设计算法框架(下文简称“框架”)，并探讨了其开发与实现的初步思路。

2 框架概览

提出的初步框架以平面较为简单的大量性建筑为研究载体，可以是乡村住宅或单元公寓等等。一般情况下，这类建筑的纵向空间复杂度较低，可由平面的特征与指标来作为建筑整体的评判依据。为了提高生成以及遍历方案的速度，将二维平面与三维模型的生成进行分离，在得到合理的二维解后再去形成相应的三维模型。总的来说，框架由形状生成(shape generation)、设计探索(design exploration)和三维模型生成(3D model generation)三大模块组成(如图2所示)。

3 准备工作

在初次应用形状文法进行形状生成之前，开发对应问题的语法及其规则一定是首要任务，它为框架提供了起始的输入数据。回顾几十年来的语法实践，可以将开发具体语法的思路归纳为三个步骤：原始语料的搜集与归纳，规则模式与策略的选择以及形状规则的进一步归纳与转换。

3.1 原始语料的搜集与归纳

一个具体语法的主要构成是形状规则，而形状规则由基本形状组成，即所谓的词汇或语料。搜集语料的任务便是设计知识获取的过程，一般能够通过三种途径获取相关的知识[4]：

1)开发设计理论；

2)从成功设计师那里获取知识或是他们设计对象时的实践经验；

3)分析特定领域中的现有对象。

第一种方式显然是最为困难的，但也暗示着可以从现有的设计理论中提取相关知识。第二种方式可以在设计工作室或公司的学习实践或合作中获得，Duarte在西扎的帮助下完成的马拉盖拉语法[5]就是此种方式的典型案例。第三种方式相对来说是最普遍且最易实现的，可以通过实地调研直接记录与测绘数据，也可以通过文献资料集或案例图纸库的查阅间接获取数据。

知识的获取相对来说并不困难，而更为重要的是如何使用这些知识，如何将它们转换为形状文法所需要的表达形式，这一过程也被称为知识的提取。提取知识即从获取的数据中归纳与提炼出设计所需要的那一部分，要理清所需为何，清晰明确的设计问题则是此项工作的基本前提。

亚历山大处理设计问题的流程可以归纳为自顶向下分解问题，以及自底向上解决问题[6](见图3)。用该方法解决问题的关键在于是否能够创造出这种层级明确的树状图解。通过对初始问题进行不同角度或程度地分解和抽象，可以得到不同的树状图解。至此，只需从底层开始，将各个元素最常见的几何构成与属性设置为形状，将对应的元素名称设为其标签，便能获得所需的基本词汇。获得基本词汇之后，还需掌握它们之间的空间组合关系，进而逐层向上，得到最终的设计目标。

3.2 规则模式与策略的选择

规则模式是对设计过程的反映，语法呈现哪种规则模式取决于将设计问题分解成何种形式。Knight将现有语法实践中的规则模式归纳三种类型[7]：

1)网格型(Grid)：建筑存在明确的轴网关系，这种类型的建筑一般也从定义轴网开始。除帕拉迪奥语法外，日本茶室语法[8]、营造法式语法[9]也属于这种类型。

2)叠加型(Addition)：建筑没有明确的轴网关系，通常以某个核心空间开始设计，其他空间依次添加到设计中，如草原式住宅语法[10]、安妮女王住宅语法[11]等。

3)细分型(Subdivision)：通常以一条明确的边界开始，逐层对内部进行划分，如冰射线语法[12]、马拉盖拉语法等。

这三种典型的规则模式反映出自上而下和自下而上的设计方法，网格与细分属于前者，叠加属于后者。这些模式正是语法通用化的关键，同一种风格的建筑可以由不同的规则模式表征，同一规则模型也可以生成不同类型的建筑[13]。

从整个应用过程来看，利用形状文法生成新设计的策略可以被归纳为以下四种[14]：

第一种策略即标准的分析型文法，起点是一组现有的设计，分析这些设计得到语法实例。语法生成的设计包括原始设计和新设计，就像帕拉迪奥语法一样。因此仅通过分析型文法就有可能生成新颖的设计。但这些新设计将被限制在与原始设计相同的风格(见图4(a))。

第二种策略与第一种策略的开始方式相同，但是为了进一步扩展设计的可能性并超越原来的风格，额外定义了规则转换。这些规则转换将原始语法的规则作为输入，生成的新语法与新规则作为输出。新语法产生了一套与原有设计有联系，但风格不同的新设计(见图4(b))。

第三种策略与第二种策略相似。它们有相同的出发点。然而，规则转换不是定义于原有语法，而是直接作用于原有语法生成的设计。换句话说，不是定义规则转换，而是定义转换规则。当采取这种策略时，设计师正专注于某一位客户设计一栋房子，而不是为所有潜在客户设计一类房子(见图4(c))。

第四种策略与上一种本质上相同。但是在流程上省略了开发原始语法的步骤，而是直接考虑如何将现存设计转换成新设计的转换语法。当原始设计没有分析的必要时，可以采取这种策略(见图4(d))。

到目前为止，已经解决了初始条件输入中最为重要的形状规则的开发问题。“环境配置”和“控制条件”的作用是对形状的生成施加限制条件，避免产生太多无效解，可根据具体的实际需求进行添加。

4 形状生成

形状的生成可以借助现有的通用形状文法解释器或自建参数化模型，两者的数据基础都是上一步完成的形状规则。使用通用解释器，可以像在图纸上绘制规则那样定义形状规则，它会在后台将其自动编译为包含“形状识别”和“形状替换”功能的函数。解释器的作用相当于将原本类似“黑盒”的复杂程序以形状规则的形式进行了可视化，并且还能够可视化地修改它们，它会自动地将该函数进行更新。这些都是参数化模型所做不到的，参数化规则的创建只能依赖参考形状规则的生成逻辑手动完成，且规则的修改也需要人为地调整其算法逻辑。

使用通用解释器能够简单地实现规则的自动推演，而参数化模型想要实现该功能则十分困难。另外，使用通用解释器来存储形状规则，可以更加容易地实现规则的通用化，因为组成这些规则的基础数据结构是一致的，不同语法之间的规则能够相互产生作用。而这一点用参数化模型同样难以实现，它的规则不是由形状组成，而是各不相同的功能模块，只能实现接口之间的相互通信。

但是，通用解释器的开发十分困难，只能依赖于专业的程序员，而诸如Grasshopper，Dynamo平台下创建的参数化模型则被大多数设计师所熟悉，即使这仅意味着对形状规则推演的模拟，但也能达到相同的设计结果，开发的过程也相对更加灵活，因此能够被大多数设计师所接受。这时的形状规则，则只是作为可视化的知识模型，在开发和设计过程中起着指导作用。

按需选择通用解释器或参数化模型其中一种，即可完成形状的生成。但需要注意的是，框架暂未嵌入固定的通用解释器以供形状计算，而参数化模型也需根据实际案例进行开发，这里仅规定数据的接口，即它们都应输出带标签的二维平面作为最终的生成结果。经过设计师筛选后，这些结果可以用来生成三维模型，或借助设计探索模块执行进一步的优化。

5 设计探索

设计的探索不是必须的，这种需求一般发生在设计师对某个复杂问题的求解方式没有明确思路，或者说希望生成的解符合某个或某几个既定的目标而没有较好实现思路的情况下。相反，如果一个问题有清晰的解决思路，则应该使用更加清晰高效的算法，仍使用探索模式将会十分低效。

5.1 评估函数

评估模块的实现可以是显式的，也可以是隐式的。显式实现可以通过设定具体的常量、代数表达式或更为复杂的算法函数来进行判断；而隐式实现则是指直接由设计师通过主观视觉分析进行筛选，该模块只表征一个评估的形式过程而不包含具体的内容。评估手段或评估函数的选择并没有固定的标准，主要取决于设计的目标以及是否需要进行设计探索。如果需要进行设计的探索，则评估模块必须显式的实现，因为探索模块的执行依赖于评估函数的结果。

5.2 语法进化

语法进化的前提是利用程序将规则自动化应用，即规则的自动推演，通常使用“形状代码(shape code)”来表达规则序列(规则序号的线性排列)[15]，而规则序列则可以作为形状文法生成的具体方案(表型)的表征形式，因此“shape code”即为基因型。将规则序列作为基因型不会对语法本身做出任何改进，它可以将结果限制在该语法所规定的解空间内，以确保设计在风格范围内变化。但若需要增强其设计探索的能力，则可以对语法本身进行进化，即形状规则的进化。这种情形下，则需要将组成规则的元素变为程序所需要的基因型，可以是形状词汇、形状参数或是规则参数等等。规则参数也可以与规则序列同时交互，发生更加复杂的变化。

5.3 形状进化

“形状进化”即为设计结果的进一步优化。这种方式需要对设计结果进一步建模，将它的几何或拓扑等属性参数化，以便于将它们作为基因型进行交叉与变异。它的进一步生成与进化不会再与形状文法有关的程序进行交互，有关它的具体操作步骤可参见其他应用遗传算法进行平面进化的案例。虽然与形状文法的算法逻辑或过程无关，但它仍然可以是框架中的重要一环，这也能证明各种算法模块之间除可以直接配合，也可间接地利用共同的接口进行交互。

6 模型生成

在所有的平面元素全部确定之后，可以开始进行三维模型的生成与映射。若是利用通用解释器得到的带标签的二维平面，墙体等三维构件的生成最关键的是依赖对标签的自动识别，而在参数化模型中则是依靠手动输入正确的基线。只要不同风格的同类构件能够识别同一个“基线”，它们之间就可以方便地进行模块化替换。随着需求的增加，不断地绘制或导入新构件即可。关于模型映射，在grasshopper平台上一个简单的实现是以内置模块“Box Mapping”与“Bounding Box”为核心的求解方法。该过程中最需要注意的点就是源形状与目标形状基准平面的设定，以保证模型之间的映射能够适应不同的方向(见图5)。

7 结语

该框架可以有效完善基于形状文法的设计流，使其更加适应于实际的设计场景。此外，该框架仅在一定程度上规定了系统的运行流程与交互接口，但没有限定每个模块的具体实现，它们是可被替换的，应该以具体研究载体的实际问题与需求为准来开发最合适的实现算法。当框架得到进一步实现和完善后，能够具备对某个大量性建筑进行大规模定制化设计的潜力，以此来提高设计的质量与效率。