简介Cityengine城市规划02规则库是一套面向Cityengine用户的规则扩展包适用于城市规划、景观设计与数字城市模拟等场景能解决从零搭建复杂城市模型效率低的问题。压缩包共8个文件以cgb规则文件、cga脚本、xml配置、project工程文件及pydevproject配置为主整包仅36KB轻量紧凑便于快速导入现有项目。规则覆盖地形、建筑、道路等核心生成逻辑cgb负责批量控制建筑形态cga脚本支持精细建模和参数化设计xml与project文件可快速同步工程环境目录包含rules、scripts、assets等模块结构清晰便于按需调用和二次开发。通过调整规则参数可实时预览城市景观变化帮助设计者高效对比多种规划方案从而缩短规划迭代周期。已有1108人学习下载适合希望快速产出城市方案、深入理解Cityengine规则建模的中高级用户使用。1. 城市规划02规则库为什么值得自己动手搭接触过Cityengine的朋友应该都有同感官方自带的那套Essentials规则库用来做概念验证和简单体块推演够用但一旦落到真实的城市规划项目——比如要控制地块容积率、要生成退线一致的沿街立面、要按道路等级自动分配建筑高度——就明显不够用了。市面上流传的“城市规划02规则库”这类打包资源本质上就是别人把自己项目里打磨过的CGA规则按场景归好类让你少走弯路。但问题在于规则库这东西高度依赖项目语境别人调好的参数搬到你的地块上大概率会翻车。我的建议是不要只当“下载者”要把规则库当成一套“半成品模板”来研究。02这套规则库的典型价值在于它涵盖了城市规划中最常碰到的几个生成逻辑道路网格驱动的分区、地块退线与建筑控制线、容积率与建筑高度联动、街墙立面分割。把它的骨架拆出来理解每个文件里藏着的参数和坑再改写成自己能维护的一套规则才是投入这个方向最值得做的事。这篇文章不打算带你复现某个具体版本的规则库因为我手里也没有“城市规划02”的原始工程包。我会按这套规则库最常见的组织方式和从业习惯把一条从导入到调参再到自己改造的完整路径讲清楚适合刚入手Cityengine的规划师也适合想把自己规则库沉淀成可复用资产的老手。2. 拆开规则库看门道CGA文件结构、坐标系与初始配置2.1 一个规则库压缩包里通常装了什么无论从哪个渠道拿到的“城市规划02规则库”解开压缩包后文件结构大体逃不出下面这几类我先给出一份常见清单方便你对号入座rules/目录存放.cga规则文件这是规则库的核心。assets/目录存放贴图、模型、代理Mesh如树、路灯、车辆。datasets/目录存放测试用的地形、道路中心线、用地边界等SHP数据。maps/目录存放地面贴图或卫星图。scenes/目录Cityengine场景文件双击可以直接打开看效果。README.pdf / 说明.txt作者写的使用说明和参数对照表。拿到手第一步不是双击场景而是先把.cga文件用文本编辑器全部打开看一遍。重点看三件事文件头部有没有Group和Parameter注解、规则里用了哪些内置函数、是否有外部依赖比如import其他规则文件。很多规则库翻车都是因为路径依赖断了——作者在本机用的绝对路径你这边目录结构一变就报错。2.2 坐标系不统一是所有城市项目的第一个坑我自己接过好几个从网上下载的规则库最常碰到的问题不是规则语法错误而是SHP数据的坐标系和场景不匹配。规则库里的CGA代码本身不会写“坐标系”这种东西它只负责在给定几何体上做挤出、分割、拉伸但地形的投影坐标系如果和道路中心线不一致生成出来的模型会歪到离谱甚至整体跑到地球另一边。解决办法是在导入规则库自带的SHP数据之前先看一遍它的.prj文件。常见做法是在ArcGIS Pro或QGIS里把所有输入数据的坐标系统一转成WGS 1984 UTM Zone 对应分带或者如果项目范围不大直接用Web Mercator也行。注意Cityengine场景创建时选的坐标系会参与到所有后续地理参考计算如果场景坐标是NAD83 / UTM zone 17N而你的数据是WGS84即使数值上看起来差不多生成建筑的墙角点也可能偏移几十公分到几米这在规划报建阶段是不能接受的。我一般会在拿到规则库后做这样一次清洗动作把所有矢量数据重新导出坐标系强制指定为当前场景坐标系属性表里只保留规划必需字段比如用地性质、容积率、建筑限高、退线距离多余字段全部删掉。原因很简单CGA里用attribute读取字段是按名称匹配的字段名不一致或者类型不对字符串当成数字用规则会以默认值运行而不是报错。这种静默失败最坑人——看起来生成成功了但所有建筑高度都是规则库里写的默认值你拿到的结果没有任何规划意义。2.3 初始规则怎么挂从Shape到第一个建筑体块规则库不是双击就能用的它必须挂接到“初始Shape”上。Cityengine里初始Shape通常来自SHP导入的用地边界或道路中心线规则库做的事情就是从这些Shape出发一步步“长”出建筑和街道。拿最常见的“用地生成建筑”举例一个典型的初始规则链长这样Lot -- innerRect // 取地块内最大内接矩形作为建筑控制线 extrude(world.y, buildingHeight) // 按建筑高度挤出体块 massing // 交给体块细化规则代码逻辑拆开看Lot是CGA的起始规则每个输入的地块Shape都会自动从Lot开始执行。innerRect的作用是收缩地图形状到内接矩形这相当于把不规则的用地边界“去角”模拟的是建筑退线让出的空间。extrude是沿世界Y轴挤出挤出高度由buildingHeight属性决定这个属性可以在规则文件里定义默认值也可以在Cityengine的Inspector面板里直接覆盖。参数这么调如果buildingHeight不希望在规则文件里写死而是从SHP属性表里读取需要把它定义成Parameter并且勾选“从Attributes导入”。我在项目里的一般做法是Group(规划控制, true) Parameter attr buildingHeight 24 // 默认24米约8层住宅 Lot -- innerRect extrude(world.y, buildingHeight) comp(f) { top: roof_common | side: facade_wall }Group(规划控制, true)这个注解意思是这个属性会出现在Cityengine属性面板的“规划控制”分组里并且第一项显示。comp(f)是CGA里最常用的组件分解函数——top和side分别把挤出的顶面和侧面分出来交给不同的后续规则处理。这个结构几乎是所有规划规则库的骨架02规则库里绝大多数复杂的生成逻辑都是从这个简单的分形结构繁衍出来的。新手最容易忽略的是innerRect带来的人工干预——它相当于无脑把边界切成了矩形。如果地块本身是L形或带弧形边界这样切会丢面积。02规则库里通常会在Lot后面做一个判断Lot -- case area(geometry) 2000: setback(5) { all: innerRect | remainder: yard } else: offset(-3) extrude(world.y, 12)逻辑说明area(geometry)是CGA内置的面积函数按地块面积分两套生成路径——大地块做退线和内接矩形小地块直接偏移裁剪后挤出免得生成过于琐碎的建筑轮廓。这种分支写法在解决实际城市街区时比单一路径实用得多。3. 手动搭一套“02风格”规则从道路骨架到街区生成3.1 用道路中心线驱动街区地块划分规则库名字里有“城市规划”四个字说明它的核心场景不是单体建筑而是“片区生成”。常见做法是先有道路中心线SHP用Cityengine的Street功能生成道路网络再让规则库自动把道路围合的区域切成地块。这个过程你完全可以脱离下载规则库自己做而且更能理解规则库的本质。首先用一段最简单的规则来控制道路断面Street -- s(12, 0, 12) // 道路宽度24米双向四车道典型值 alignScopeToAxes(y) extrude(world.y, 0) // 道路本身不出高度 split(x) { 3 : sidewalk | 9 : road | 9 : road | 3 : sidewalk }alignScopeToAxes(y)的作用是把当前Scope对齐到世界坐标轴否则s(12, 0, 12)的展开方向会沿着道路中心线的切向和法向旋转侧分带会扭着走。split(x)横向切分3米人行道9米车行道9米车行道3米人行道中间不用分隔带这是老城区窄路网的做法。如果是城市主干道把road部分改成split(x) { 11 : road | 2 : median | 11 : road }就好。当道路网络切割完地形之后地块边界就已经自动生成了。这时关键一步是给每个地块打标签——用地性质。02规则库通常的做法是读取SHP属性表里的LANDUSE字段在CGA里用一个case链做分支Lot -- case landuse R2 : residential_low // 二类居住多层 case landuse R3 : residential_high // 三类居住高层 case landuse C2 : commercial_street // 商业临街 case landuse G1 : park_green // 公园绿地 else : mixed_use // 默认混合属性匹配的原理是Cityengine在生成时会把SHP属性表并入Shape的属性集合你在attr landuse前加了Parameter注解它就会优先从属性表里读值规则文件里的默认值只是兜底。这里有个容易踩的坑SHP属性表里的字符串如果带空格或中文全角字符case R2这种精确匹配不会报错但会全部落到else分支。解决方法是导入前在GIS里做一次字段清理确保枚举值只有英文字母和数字。3.2 容积率、建筑高度和退线三个参数的联动写法规划规则库的“灵魂”在于让三个核心控制指标互相约束而不是各自独立。比如地块面积1000平方米、容积率2.0那建筑总面积就是2000平方米。如果限高60米、层高按3米算最多20层标准层面积就是2000/20100平方米——这个数字如果小于建筑核心筒加电梯所需面积方案就不成立。在CGA里做这种联动计算规则库常见实现是Group(规划控制, true) Parameter attr FAR 2.0 // 容积率 Group(规划控制, true) Parameter attr maxHeight 60 // 建筑限高单位米 Group(规划控制, true) Parameter attr floorHeight 3.0 // 标准层高 Lot -- produceBuilding produceBuilding -- case area(geometry) * FAR 0: set(floorCount, min(area(geometry) * FAR / (innerRectArea * 0.7), maxHeight / floorHeight)) innerRect extrude(world.y, floorCount * floorHeight) comp(f) { top: roof_common | side: facade_wall } else: NIL先解释逻辑再讲参数。area(geometry) * FAR得出总建筑面积上限innerRectArea是内接矩形的底面积乘0.7是估算核心筒和设备管井占掉的标准层得房率系数。两者相除得到理论层数再用min()跟maxHeight / floorHeight做约束取较小值。这样算出来的层数既满足容积率又不会冲破限高线。这个公式里的0.7不是物理定律是经验值。塔楼得房率在0.65到0.75之间板楼可以在0.8以上。02规则库里一般把它做成一个可调属性floorPlateEfficiency而不是写死在表达式里不然项目一变就得改规则源码。退线逻辑放在innerRect之前用setback函数实现Lot -- setback(southSetback) { all: innerRect | remainder: buildingFootprint }这条代码的含义是从地块边界向内收缩southSetback距离生成建筑控制线remainder保留的是退线后的剩余区域也就是建筑可落位的范围。设置朝南退线要单独大一些是因为日照和消防要求通常对南向更严格。实际操作时02规则库会把退线分成frontSetback / sideSetback / rearSetback三个独立属性分别从地块不同方向取值但CGA原生没有“按方向取不同退线距离”的语法常见做法是把地块四个边分别抽出后各自执行操作Lot -- splitFront splitFront -- alignScopeToGeometry(y, anyEdge, longest) setback(frontSetback) { all: lotBody }这段代码看着绕实际在干一件事把地块沿最长边方向对齐Scope然后对前沿做退线。CGA执行规则是以Scope为中心的alignScopeToGeometry就是给后面setback一个明确的参考方向否则退线会同时发生在所有边跟规划条件不一致。3.3 沿街立面怎么自动分段街墙规则城市规划规则库里另一个高价值模块是“街墙”——就是临街那排建筑立面如何连续、如何断口、檐口高度怎么控制。02规则库常见的做法是对临街地块生成建筑后不直接做立面细节而是在facade_wall规则里按楼层和开间两个维度做分割。facade_wall -- split(y) { floorHeight : floor | ~1 : parapet } floor -- split(x) { 4.2 : window_bay | 2.4 : window_bay | 4.2 : window_bay }split(y)沿纵向按标准层高切分切出来的每个楼层段再交给floor规则。~1 : parapet这里的~是“占剩余空间”的意思也就是屋顶女儿墙。split(x)沿横向按开间模数切窗宽4.2米、2.4米、4.2米交替形成“三开间”的立面节奏这是沿街住宅常见的做法。参数上的讲究在于4.2这个数字是轴线尺寸还是窗边净尺寸直接决定立面比例是否好看。实际经验是轴线4.2米没问题但窗户本身应该只有2.7~3.0米宽剩下的是墙垛和窗间墙。所以更专业的写法是floor -- split(x) { 4.2 : split(x) { 0.6 : wall_pier | 3.0 : window | 0.6 : wall_pier } | 2.4 : window_bay | 4.2 : split(x) { 0.6 : wall_pier | 3.0 : window | 0.6 : wall_pier } }这样写的代价是规则层级变复杂但对最终效果的影响是决定性的——没有墙垛的分割看起来像玻璃盒子拼贴不像真实建筑。这也是借用规则库和能改造规则库的分水岭。4. 从规则到可交付成果纹理、导出与LOD切换4.1 纹理贴图资源不够时怎么自给自足城市规划项目里建筑量大如果每栋楼都用完整PBR材质渲染帧率会掉到没法操作。02规则库通常内置了三档纹理策略远景用色块材质、中景用简单窗户贴图、近景才启用完整贴图。这个策略是用lod属性控制的Hidden attr lod 2 facade_wall -- case lod 1 : color(#D0C8B8) case lod 2 : simpleFacade case lod 3 : detailedFacade else : simpleFacadeHidden表示这个属性不出现在参数面板由场景的LOD设置自动控制。这块有个容易忽略的坑网上能搜到的“cityengine纹理下载”包里很多贴图分辨率只有512x512用在近景楼栋上锯齿明显。我自己会把贴图库按用途分层放到assets/textures/下的三个子目录里文件名前缀区分L1_ / L2_ / L3_规则文件里直接引用文件名对应变量换贴图的时候只替换文件不改规则代码。贴图格式方面规则库常用tile函数把贴图平铺到立面上——这需要贴图本身是“无缝可平铺”的不然每隔几米出现一道接缝非常出戏。判断无缝最简单的方法是把贴图水平翻转接在一起看接缝是否明显。02规则库里有些下载版的贴图并不无缝生成后沿街立面像贴了膏药这算是一个常见质量问题。4.2 导出到GIS和建模软件的正确姿势规划成果最终要进ArcGIS做分析或者到3ds Max里做深化。规则库的导出路径一般有两条一是Cityengine自带的Export Models二是通过ArcGIS的Import 3D Files间接联动。直接说结论能用FBX尽量不用OBJ能用GeoJSON尽量不用SHP。建模软件这条线我常用的导出参数是一份固定配置格式: FBX 单位: Meters 轴转换: Z-Up to Y-Up如果下游是3ds Max 纹理: 勾选Embed Textures嵌入式贴图避免路径丢失 比例: 1 unit 1 meter这里的Embed Textures必须勾上否则模型文件发给别人时贴图路径指向你本机的assets目录对方打开全是灰模。这也是规则库项目交接时最容易翻车的点。另一个容易踩的是轴转换Cityengine是Y-Up3ds Max也是Y-Up但Maya是Z-Up如果下游管线是Maya得在导出时翻转坐标系。GIS分析这条线更简单但要注意导出GeoJSON时Cityengine会把地块和建筑体块都按地理坐标写出进ArcGIS Pro可以直接做天际线分析或阴影模拟。我自己常配合做的是先导出三维实体到Cityengine/export/再导一份二维建筑轮廓线底面多边形到SHP用来做A4图框里的总平面底图。二者的关系就像一个是积木一个是积木的投影缺了哪个都不方便。4.3 LOD切换在视口和最终渲染之间的差异刚才提到lod属性控制材质细节但视口里看到的和最终渲染输出的一定不一样。规划规则库生成几万栋建筑后你把视口LOD调到1一秒钟就能转圈不卡但需要输出高清鸟瞰图时必须把视口的LOD强行拉到3全景渲染才不至于全部是色块。这里有个技巧不要全局调LOD用Culling和Visibility按相机距离自动切换。Cityengine的Scene面板里有LOD开关配合规则库里的lod属性就能做到“近处看细节远处看色彩”。整套逻辑和游戏引擎的Level of Detail如出一辙只不过规则库里控制的是城市规划模型不是游戏场景。把这一层吃透就不需要每次出图时手动等烘焙。5. 避坑手册Cityengine规则库落地最常见的6个翻车点5.1 坐标系不一致导致建筑体块歪斜错位现象生成出来的建筑不贴合道路走向严重时偏移数百米。原因SHP数据的投影坐标系与Cityengine场景坐标系不一致。规则库代码本身没有错错在输入数据的地球参考。解决在导入前统一用ArcToolbox → Data Management Tools → Project把所有矢量数据转换成与场景相同的坐标系。转换完成后在Cityengine里选中任意地块Shape右键Inspect Model看它的中心点经纬度是否和预期一致。别相信“看起来差不多”投影差几度在天文尺度上看起来差不多在城市尺度上差出去一整个街区。5.2 属性表字段名不匹配导致所有地块一个样现象明明SHP里每块地的容积率不同生成出来的建筑高度全部相同。原因attr FAR定义的属性名和SHP字段名不一致或字段类型是文本而非数值。CGA在这种情况下静默使用默认值不会发出任何警告。解决打开SHP的属性表逐字段确认名称和类型。我自己的习惯是导入前在GIS里把所有规划控制字段改名为单个词比如FAR、MAXH、SETBACK然后规则文件里全部小写匹配。别在字段名里用空格和中文字符CGA解析器对Unicode变量名的支持时好时坏——搜“cityengine规则库”时看到过不少问这个的帖子基本都是字段名带中文导致的。5.3 innerRect过度切割导致地块面积大量丢失现象异形地块生成后建筑轮廓比预想小很多容积率永远做不满。原因innerRect在地块不规则时切掉了过多面积规则库没有做面积阈值判断。解决在规则里加一个面积判断分支或者干脆不用innerRect改用offset(-3)做简单偏移。对于正式项目我习惯写死一个最小面积阈值如果innerRect之后面积小于原始面积的40%就退回用偏移策略。这属于规则库常见缺点的修补方案一句case areaCondition就能兜住。5.4 贴图文件路径是绝对路径导致素材全部丢失现象别人发来的场景在你电脑上打开建筑全是灰模控制台报一堆纹理加载失败。原因规则库里贴图路径写成了C:/Users/xxx/Documents/...的绝对路径换电脑后全部失效。解决规则文件里一律用相对路径开头定位到assets/目录。CGA引擎是按场景文件所在目录解析相对路径的只要assets和rules跟着场景走不会丢。这也是发布规则库的标准做法很多人忘记这一条。5.5 地面起伏导致建筑一半埋在地里现象山地地形上建筑底部有时没入山坡看起来像从地里长出来的。原因规则只做了法向挤出忽略了地形高程差异。解决在Lot规则前加s(0, 0, 0)做一个零高度占位然后用alignScopeToGeometry(y, anyEdge, longest)对齐到地形的切平面再把建筑整个抬升到地表最高点。完整写法一般不写在这个帖子范围内但这属于规则库改良的重点没有哪个公开规则库能直接解决所有地块的高差问题。5.6 规则文件用英文报错看不懂怎么查现象CGA编译报错信息里提到extrude: Operation failed on shape新手不知道去哪找问题。原因CGA生成的几何体在某一步出现了退化面积为零、方向向量垂直视口里找不到具体位置。解决点开Console窗口报错会定位到具体规则文件和行号。先看是哪个规则文件报错然后逐行排查。经验是90%的Operation failed都出在split或setback的数值上——比如setback(3)但地块宽度只有2米退线3米会把整个形退没。解决方法是加一个case判断地块太小时直接跳过退线步骤。6. 把下载的规则库变成自己的生产力一个可复用的改造流程这一章讲如何把从网上下载的“城市规划02规则库”这类资源改造成自己团队能长期维护的资产。步骤本身不复杂但环环相扣省掉哪一步后面都会加倍还回来。第一步建立规则库版本目录。不要在一个rules/文件夹里堆几十个.cga文件一定要分割成01_basic/基础几何操作、02_street/道路生成、03_lot/地块划分、04_building/建筑生成、05_detail/立面与室内。02规则库大概率是扁平结构直接照这个结构重组每个文件夹内配一个README.md写明每个规则文件的输入输出和依赖。第二步把所有魔法数字升级为命名属性。比如4.2这个开间尺寸应该定义成Group(立面控制) attr bayWidth 4.2。这样将来要改成公建大开间8.4米时不用进规则文件里逐行替换直接在Inspector面板调。魔法数字是规则库最容易积累技术债的地方——凡是你不理解的数字写下来它是什么含义下次改的时候才不会被迫猜。第三步建立测试数据集与基准测试。每个规则库都配套一个小范围SHP——常见是一块200米x300米的地块包含住宅、商业、学校三种用地。每次改动规则先在测试集上生成一遍并截图记录总建筑体量、地块覆盖率、平均建筑高度三项指标。没有这种基准你会在调参中失去方向感最后只能靠肉眼判断“好像差不多了”。第四步写清依赖关系和处理约定。规则库的输入SHP必须有哪些字段字段的取值范围是什么哪个字段决定哪条规则分支全部写进一个CONFIG.md里。这一步很多人嫌烦但这是“下载别人的规则库”和“拥有自己的规则库”的分界线。第五步封装成果物。当规则稳定后把用到的纹理和模型抽到assets/custom/目录把规则和资产打成一个新场景确认相对路径全部可用再导出一个带LOD的FBX做交付验证。曾经出过一次低级的坑规则文件里用了中文命名纹理 ——texture_zhangsan.png之类同事的英文操作系统纹理扫描直接失败最后全部重命名为英文字母才解决。从那天起规则库里命名只用[a-z0-9_]这是用血泪换来的习惯。整个改造流程完成之后规则库才真正变成“你的工具”。你不需要记住每一个规则文件的代码但清楚哪个文件承载哪类控制逻辑、哪个参数控制哪个规划指标——这比任何打包好的规则库都有价值。回想我做过的几个项目最值得的投资不是找更多现成规则库而是把一套规则改造到完全贴合自己工作流的那一个版本。过程很枯燥但每次新项目像套模板一样跑出合格的规划模型时都会觉得当初的改造值回票价。希望这篇拆解对你有所帮助动手试起来吧。本文还有配套的精品资源点击获取