企业官网建设流程全解析

简介：面向Cityengine用户的大楼与厂房规则库压缩包，适合需要快速生成城市工业建筑与高层住宅的设计师、规划师和三维建模学习者。核心是17个cga规则文件，能依据城市规划要求设置建筑高度、立面细节、屋顶类型及厂房内部生产区/仓储区/办公区划分，并通过随机化参数生成形态各异的建筑群；同时配有172个obj三维模型、84个mtl材质库及725张jpg贴图，用于提升模型真实感。压缩包共1257个文件，总大小232.69MB，除规则和素材外还包含atx分类索引、gdbtable地理数据库表及cgb编译缓存，便于在Cityengine中直接导入和调试；其中obj、png与mtl相互配套，可直接用于渲染预览，gdb与tif等空间数据则为真实地理场景导入提供基础。该资源已有443人学习浏览，可直接套用规则或修改模板，大大缩短城市场景搭建周期，适合用于规划方案推敲、环境影响模拟和地产可视化展示。

1. Cityengine大楼与厂房规则库：先搞清规则里的门道，再谈批量建模

很多人拿到Cityengine大楼与厂房规则库，第一反应是赶紧把压缩包拖进软件里按Generate，结果要么模型糊成一团，要么规则怎么都不生效。我最初也是这样，后来把一个带厂房和大楼的街区项目反复生成了几十遍，才把规则库的脾气摸透。这个规则库解决的事情很具体：把“手动拉盒子、贴材质、摆窗户”的重复劳动，变成由CGA规则驱动的参数化生成，让一栋楼、一片厂房、甚至一整条街能在几十秒内批量成型。适合正在用CityEngine做规划方案比选、城市设计推演或建筑群快速建模的人，也对想学规则写法的新手有参考价值。需要留意的是，解压后不要被一堆.atx系统文件唬住，那些是地理数据库的元数据快照，不是规则文件，真正干活的是里面的.cga规则和配套的资产文件夹。

2. 规则库内部结构：从.atx系统文件到CGA规则的组织方式

2.1 压缩包解析：哪些文件是规则实体，哪些是依赖

我第一次解压这个规则库时，看到一长串文件名，比如a00000005.CatItemTypesByName.atx、a00000006.FDO_UUID.atx、a00000007.CatRelTypesByDestTypeID.atx，第一反应是“是不是下载到损坏文件了”。后来对比了GIS平台生成的文件结构才明白，这些.atx是地理数据库的XML目录文件，由数据管理系统在维护对象类型、对象关系、UUID索引时自动生成，它们描述的是地理数据库中要素类、关系类和字段的元信息，并不需要你用编辑器打开，也不需要手工处理。

真正需要在CityEngine里打交道的是规则库的主体：以.cga结尾的规则文件、贴图纹理、可能还有部分模型资产和属性表。压缩包里把.atx也一起打包，大概率是作者把建筑底面、地块和属性数据放在地理数据库里统一管理，导出时系统表被一并带上。我的习惯是先解压到独立目录，再按文件类型分类：.atx归入依赖目录，.cga归入规则目录，纹理归入assets目录。若解压后暂时找不到.cga文件，就检查是否套了一层子目录——这个zip很常见的问题是把工程根目录再包一层。用“打开文件位置”确认一下目录层级，比在软件里瞎找要省事得多。

地理数据库的系统表与CityEngine规则库之间的关系，可以简单理解为：规则负责“怎么长”，地理数据库负责“在哪长、长成什么基底”。大楼和厂房的生成如果接入了GIS数据，规则会从属性表里读楼高、层数、用地性质等字段，再决定每个地块生成的形态。这也解释了为什么规则库要连带打包这些.atx文件：它们在桌面GIS软件里注册地理数据库时会被访问，帮助软件正确识别要素类型和关系。若你只是用CityEngine自带的地块做纯规则建模，这些.atx不会参与生成，放在一边即可。

2.2 CGA规则如何把一块地变成一栋楼

这个规则库的核心是CGA规则文件。CGA的写法和其他编程语言不太一样，它采用的是“形状文法”的思维：先有一条初始形状（通常是一块闭合的面），规则函数对这个面做拉伸、切分、组件分割，逐步细化出楼体、立面、窗户、屋顶。最基础的三板斧是extrude（拉伸）、comp（组件分割）、split（切分）。

以典型的办公楼规则为例，常见的规则链是：地块面先按照地块退缩要求生成建筑基底，然后根据楼层高度和楼层数做拉伸，形成体块；体块再通过comp分成侧面和顶面；侧面按层高split成一层一层的楼板，再在每层里按窗间墙尺寸split出窗户和墙垛。这套“拉伸—分割—细化”的链条，就是这个大楼规则库的核心建模逻辑。用熟了之后，你会发现大楼和厂房的差别主要在参数和具体分段的控制上，底层思路其实一致。

我在看规则文件的时候有个习惯：先打开入口规则，找@StartRule标注的函数，跟着函数的调用顺序读一遍，就能知道整个建筑生成流程的主线。比如看到某个函数里先调用了setback，后又调用了extrude和comp，那基本可以判断生成顺序是“先退线、再拉伸、再分区”。读规则不需要逐行会写，能看懂调用链条，后面调参数时才不至于改错地方。

2.3 规则资产引用体系：贴图、模型和数据表的挂接方式

规则库不只是写满函数的.cga文件，它还要引用外部资产。从zip里解压出来的assets目录一般放贴图，可能还有obj或fbx格式的小模型，规则文件里通过fileBrowser和set(material)这类方式挂接。贴图路径如果写的是绝对路径，换电脑后很容易裂开，所以我通常会把assets目录和规则目录保持相对位置，在CityEngine里用工作空间方式引用，不直接双击打开规则文件里的外部路径。

属性数据表在这个规则库里扮演的角色容易被忽视。厂房规则里如果绑定了“结构类型”字段，规则会根据字段值切换钢结构、框架结构或混合结构的立面表达；办公大楼规则可能绑定“地块容积率”或“限高”，通过字段驱动楼栋高度。属性表通过Join方式挂到Shape图层上，规则里用attr声明变量去接收字段值。做地块批量生成时，直接在属性表里改数字就能控制一批建筑的形态，这个能力是规则库比手工建模值钱的地方。

3. 导入与首次复现：把规则库装进CityEngine并生成第一栋楼

3.1 工程目录规范与导入步骤

拿到zip后，不要急着往CityEngine里拖。先把压缩包解压到CityEngine工程能找到的位置。我的做法是放到工程目录下的rules文件夹里，保持目录结构为rules/Cityengine大楼与厂房规则库/，这样规则里的相对路径不容易断。CityEngine的工程目录和Windows普通文件夹不太一样，工程文件里记录了工作空间引用，把资源放错层会导致后续找不到纹理。

导入方式有两种路径：一种是在CityEngine里用“导入工作空间”的方式把整个目录引进来，适合需要保留目录层级的情况；另一种是直接把规则文件夹拖到视口的图层区域，软件会按文件夹结构一次性导入。我常用第一种，因为模块化目录结构在后续维护时可读性更强。

导入完成后，检查图层管理器里是否出现了一个新的Shape图层。如果zip里带了示例地块，画布上应该能看到一块或多块闭合多边形；如果没有，需要自己画一个矩形作为测试面。测试地块不需要太复杂，画一个30米×40米的矩形即可验证规则生成的主体逻辑。

3.2 规则入口文件与初始参数确认

打开规则浏览器，定位到该规则库下的.cga文件。文件名带有“大楼”或“厂房”标识时，很容易找到入口。规则库通常会分多个文件：一个作为总入口，若干个子文件被include进来，分别处理楼体、立面、屋顶、附属构件。这就像写程序时的模块拆分，好处是改厂房立面时不用牵连办公楼的规则。

确认入口规则时看两点：第一，是否有@StartRule标注，有标注的函数才是生成起点；第二，入口函数接收的参数类型是否和画布上的地块匹配。常见的不匹配情况是规则要求地块带有“地块类型”属性，但你画的多边形没有这个属性，这时生成会报错或跳过。处理办法是选中测试地块后，在属性面板手动补一个字段值。

参数面板上的初始值也值得扫一眼。楼层数量、层高、基底退缩、屋顶样式是出现频率最高的几个参数。默认值不一定适合你的测试地块，首次复现时先把楼层数量设为4、层高设为3.3米，地块退缩设为0，等规则跑通后再逐步调回正式参数。这样能排除“地块太小但楼层太高”导致的视觉混乱。

3.3 用规则包生成建筑的全流程

下面以一次完整的规则应用流程为例，从选择地块到生成模型，给出可复现的操作序列。

// 示例：CGA规则入口——把地块拉伸成大楼体块，再分割立面 // 这是规则库中最常见的入口写法，实际文件名以解压后的.cga为准 @StartRule Lot --> setback(0) { all: Base } // 先做退线，0表示不做退缩，便于测试 Base --> extrude(floorHeight * floorCount) Mass // 按层高乘层数拉伸出体块 Mass --> comp(f) { side: Facade | top: Roof } // 体块组件分割：侧面进入立面规则 Facade --> split(y) { floorHeight: Floor }* // 按层高切出一层层楼板 Floor --> split(x) { wallWidth: Wall | tileWidth: Tile }*

这段逻辑说明：第一步setback把原始地块向内退缩，参数0表示不退缩，便于看到完整轮廓；第二步extrude以“层高×楼层数”作为拉伸高度，生成体块；第三步comp按面方向拆分体块，把侧面交给Facade，顶面交给Roof；第四步沿Y轴按层高逐层切分，得到楼层；第五步在楼层平面上沿X轴切分出墙段和窗洞单元。参数说明：floorHeight和floorCount都来自规则文件头部声明，可在属性面板覆盖；wallWidth和tileWidth控制立面节奏，想得到窄窗就把tileWidth改小。

在CityEngine的视口里选中测试地块，右键选择“应用规则”，选中刚才确认过入口的那个.cga文件，点击生成。观察结果时建议先看体块是否生成，再看立面是否有分段，最后看屋顶是否存在。如果体块没出来，先检查地块是否闭合、是否自相交；如果体块出来了但立面没有窗户纹理，优先检查贴图路径是否有效。

城市设计里批量操作时，流程相似：选中整个图层的多个地块，应用同一套规则文件，然后按下生成按钮。每个地块会独立读取自己的属性字段值，因此同一套规则可以生成形态差异很大的建筑群。第一次跑通后，再逐个调整参数，不建议一开始就在完整地块上反复试错。

4. 参数调整与批量生成：厂房、塔楼与随机化控制

4.1 关键参数表与语义

规则库中高频出现的参数通常集中在体量、立面、屋顶三类。下面这张参数表整理了常见的可调项，新项目上手时按这个顺序过一遍，能少走弯路。

参数语义上要区分两类：几何参数和材质参数。层高、楼层数、退缩属于几何参数，直接改变骨架；贴图路径、颜色、粗糙度属于材质参数，只改外皮不改骨架。规则库把两类参数分散在文件头部，建议在头部集中声明，方便外部覆盖。CityEngine的属性面板在规则应用后还会暴露所有attr变量，这样就可以在不改代码的前提下做参数测试。

4.2 随机化与多样性控制

真实城市里的建筑群不会一模一样，规则库里的随机化机制就是为此设计的。CGA里常用seed来控制随机序列，同样一个规则文件，seed不同，生成的建筑细节就不同。常见做法是在规则头部声明一个seed变量，并在每个地块上为seed赋不同的值，这样同一个街区的建筑在层数、立面划分和屋顶样式上会产生差异，但整体风格保持统一。

看规则文件时留意random函数的用法。有的规则会用random(3, 8)控制楼层数，有的用split随机宽度实现立面节奏变化。模拟人工设计时，我一般会把随机范围控制在合理区间内：比如地块限高40米，层高3.2米，楼层数随机范围就设在8到12层，而不是让规则在3到20层之间乱跳。项目上被甲方打回来重做的翻车案例，相当一部分是随机范围给得太大，导致相邻地块的建筑比例失衡。

多样性控制的另一个手段是条件分支。厂房规则里常见“根据用地面积选择单层厂房还是多层厂房”的分支写法：地块面积小于阈值时走单层大跨方案，大于阈值时走多层框架方案。这种基于属性的分支在规则库里属于高级用法，但读懂后对逻辑控制能力提升很大。

4.3 从单栋到街区：批量应用的两种路径

批量应用规则有两条路径，适用场景不同。路径一是选中多个地块，使用同一套规则文件生成，每个地块独立计算，适合规划方案中统一风格下的批量建模。路径二是通过属性驱动生成，先在地块属性表里预设好各栋楼的层数、高度和屋顶类型，然后规则文件通过attr变量读取这些值，生成时一栋楼一个样。这条路径更适合做“带任务条件”的建设项目群模拟。

批量生成前不要忘了检查所选地块的坐标系和单位。CityEngine默认按米处理，如果导入的面数据单位不是米，生成的建筑尺寸会明显失真。厂房地块里经常有非矩形轮廓，批量生成时出现个别楼栋形体怪异的概率不低，我会在批量生成后快速检查最小边界框的尺寸，对比一下缩放比例是否合理。

批量生成后调整参数是规则库使用中最有效率的一环。选中所有生成结果，在属性面板里修改一个参数值，重新生成，整个街区就整体更新。做方案比选时，这种“改一个数，整条街变”的能力比手动修模型好用得多。但也要注意，修改参数后历史版本会被覆盖，最好先另存一个场景再改，保留一份后悔药。

5. 常见问题排查：规则应用失败与建筑变形

5.1 规则应用后没有任何模型生成

现象：选中地块并应用规则文件，点击Generate后视口里什么都没有，也没有明显的报错。我第一次遇到时以为是规则没装上，反复重导入了三四次。

原因：最常见的是地块面的法线方向反了。CityEngine的规则默认在正面生成，如果你的面是反面，拉伸和分割全部发生在背面，看起来就是“没有生成”。其次是面自相交或有悬点，几何上不是合法闭合多边形，规则无法初始化初始形状。

解决：画测试地块时养成好习惯，画完看视口里的网格法线方向，确保正面朝上；不规则地块用“校验几何”功能检查边界。规则库如果自带示例地块，先用示例地块跑一遍，确认规则本身没问题，再查自己画的地块几何。

5.2 立面生成正确但贴图拉伸严重

现象：楼体体块出来了，窗户和墙面的位置也对，但贴图像被扯开一样，纹理比例明显失真，窗户显示成一团模糊色块。

原因：常见做法是split切分之后没有重新设置投影坐标，贴图仍沿用初始地块的UV，楼层一旦被拉伸，纹理就跟着变形。规则文件里如果缺少setupProjection相关调用，这个现象几乎必然出现。

解决：在split之前，对要贴图的面重新定义投影，通常用setupProjection(0, scope.xy, 3, 3)这类调用把纹理坐标重置到以米为单位的空间。贴图参数里要注意纹理的平铺次数——大多数情况下，规则库里已有正确的投影逻辑，如果还是拉伸，检查一下是否手动改过投影相关的参数。

5.3 与GIS数据叠加时建筑错位

现象：把规则库生成的大楼放到从GIS导出的地块上，建筑整体偏离了地块边界，或者在俯视图下建筑跑到马路中间去了。

原因：数据集坐标系不一致。规则库里的地理数据库系统表记录了某个坐标系下的要素关系，导入的地块若是另一个坐标系，软件做动态投影时就会错位。这和规则文件本身无关，属于数据预处理问题。

解决：导入GIS数据前先确认坐标系，和地理数据库的坐标系保持一致；若不一致，在导入时转换为统一坐标系再生成。厂房项目里经常混用测绘数据和规划数据，这两个数据源的坐标系不一致概率最高，叠加前强制走一遍坐标统一，能躲开大部分错位问题。

5.4 厂房屋顶翻转或朝向杂乱

现象：厂房规则生成后，屋顶朝向不统一，有的屋顶法线朝天，有的朝地，俯视图看起来一块亮一块暗。

原因：和5.1类似，根因还是地块法线方向不统一。多源数据合到一起时，各来源的面的方向未必一致，导致comp分割时屋顶面的朝向各异。

解决：批量生成前，统一将地块法线朝上；生成后若发现个别屋顶反了，单独翻转该面的法线再重新生成一次。这个操作不复杂，但批量处理时容易漏，建议养成“生成后立即检查屋顶朝向”的习惯。

5.5 打开规则文件时提示找不到引用的地理数据库

现象：双击.cga文件，软件弹窗提示缺少某个地理数据库或字段信息，规则浏览器里部分规则显示异常。

原因：zip里的.atx系统表记录了与地理数据库的关联，迁移目录后相对路径失效，软件找不到原数据库，规则中对属性字段的引用也就断了。这个现象在从压缩包直接导入时最常见，因为解压后目录层级变了。

解决：把整个规则库解压到固定位置，再用工作空间导入而不是单独拖文件；确认属性字段引用的是Excel或csv表时，单独修正表路径。在规则浏览器里看到引用断裂，优先检查文件路径层级，而不是删了重新导入。

6. 进阶用法：用场景属性和外部表格驱动规则库做自动化生成

规则库用熟之后，手动操作已经不能满足生产节奏，我通常会把规则库往“属性驱动+批量生成+回归验证”这个方向推进。一个很实用的场景是：把地块的用地性质、限高、容积率整理成一张属性表，连接到Shape图层后，规则文件里通过attr声明变量去读取属性字段，生成时每块地都按自己的属性长成对应的建筑形态。流程是：先准备好带属性的地块数据，再在规则头部写上attr landUse = 0、attr maxHeight = 24等声明，然后在生成时让这些变量接收属性表里的字段值。这样一次的批量生成相当于完成了整个街区的建筑体量推导。

验证生成的建筑是否满足约束，我习惯在生成后做一轮“规则校验”而不是肉眼观察。具体技巧是：利用规则库的report功能，让规则在生成过程中输出每栋楼的层数、总高度和建筑面积，再把输出的数值与规划条件对比，检查是否超限高或超容积率。楼栋高度超限、建筑基底超范围这类问题，在数据里比在模型里看得更快。

从那以后，我每次拿到新的规则库，都强制自己走一遍“解压分类—确认入口—用测试地块跑通—批量验证—复核输出”这五步，这个习惯帮我绕过了不少看似玄学、其实只是路径和法线问题的坑。规则库里的.atx系统文件再出现时，我已经能淡定向同事解释“这是地理数据库的元数据，不用手动去动它”，而不是一脸茫然。希望这份拆解能让你少走几步弯路，把更多时间花在建筑方案本身的推敲上。

本文还有配套的精品资源，点击获取