CityEngine CGA道路规则库构建与实战解析

简介：本资源是面向城市规划师、三维建模工程师及CityEngine进阶用户的道路规则库集合，专为解决复杂城市路网快速生成与标准化建模难题而设计。资源包含1247个文件，总计202.24MB，主体为725张道路纹理与示意JPG/PNG图、172个带材质的道路OBJ模型、84个MTL材质定义文件，以及34个ATX地理索引文件、18个GDB空间数据库表和关键的CGA规则脚本（.cga）、CityEngine工程文件（.cej）与Python扩展脚本（.pydevproject），完整支撑从GIS数据导入、规则驱动建模到可视化渲染的全流程。已有1178人学习下载，适用于需高效构建主干道、支路、交叉口及附属设施（绿化带、人行道、标线、路灯等）的真实感城市环境项目。用户可直接调用预设规则生成符合现实规范的多层级道路系统，并基于CGA语法进行二次开发与本地化适配，显著提升城市数字孪生建模效率与一致性。

1. 项目概述与核心需求拆解

1.1 为什么需要一套道路规则库

做城市级三维建模的人应该都有这种感觉：真正拉开项目效率差距的，往往不是建筑体块生成得多快，而是道路系统能不能撑住全局。道路是城市的骨架，骨架出了问题，后续的建筑布局、地块划分、绿地系统全都跟着跑偏。Cityengine里的CGA规则库，尤其是道路方向的规则集，就是解决“骨架”问题最核心的资产。

我在几个实际项目里反复踩过坑之后，最大的体会是：很多人把Cityengine当成“建筑生成器”，花大量精力调楼宇规则，却忽视了道路规则库的搭建。结果就是建筑单体做得再精美，一旦放到场景里，道路交叉口衔接生硬、车道宽度不统一、人行道断断续续，整体观感立刻垮掉。反过来，如果先用一套健壮的道路规则库把路网基底打好，后续所有元素都能顺着这个骨架自然生长出来。

这套道路规则库本质上是用CGA（Computer Generated Architecture）语言封装的一组道路生成逻辑，它定义了道路如何根据属性参数自动生成路面、车道线、人行道、路缘石、绿化带，甚至交叉口的衔接方式。做得好的一套规则库，能让你在几秒钟内把一条简单的线段变成一条符合规范的城市道路，而且可以随时通过属性面板调整宽度、车道数、人行道宽度等关键参数。

1.2 这套规则库到底能解决什么问题

先列几个我在项目中遇到的典型痛点，你看看有没有共鸣：

• 手工建模道路效率极低，一条两公里的主干道，手动拉模型加贴图可能要两三天，而规则生成只需要几分钟。
• 项目中途要调整道路宽度或车道数，手工模型几乎是灾难性的返工，规则库只需要改一个数字。
• 城市级别的项目动辄几十条道路，风格不统一是常态，规则库能保证所有道路遵循同一套生成逻辑。
• 交叉口处理是最让人头疼的，规则库配合Cityengine的street network能自动处理大部分衔接问题。
• 交通标注、道路标线、斑马线这些细节，手工做会疯掉，规则化之后只是几个参数的组合。

如果你正在做智慧城市数字孪生、城市规划方案展示、游戏场景大世界搭建，或者建筑可视化的周边环境配套，这套道路规则库的思路都能直接复用。我不打算只给你一堆现成的代码文件，更想把背后“为什么这么写”“踩过哪些坑”“怎么改成自己的”讲清楚。

2. CGA规则设计的整体思路与选型分析

2.1 CGA规则体系里道路生成的基本逻辑

在Cityengine里，道路不是靠“画”出来的，是靠“算”出来的。它的底层逻辑是：你先通过GIS数据导入或者手绘得到道路中心线，然后CGA规则沿着中心线以profile（横断面）的方式向两侧挤出几何体。

这里有个关键的概念要理解：CGA处理道路的方式和建筑规则有本质差异。建筑规则面对的是一个独立的shape（形状）对象，而道路规则面对的是street network里的graph segment（图段）。每个图段带有起始节点、终止节点、长度、方向等拓扑信息。规则要做的事情，就是沿着这个图段的走向，把横断面不断复制、延伸，最终形成一条三维道路。

打个比方你就明白了：道路生成很像3D打印。中心线是打印机运动的路径，横断面是喷头挤出的材料截面，规则参数就是控制挤出速度、层高、材料类型的旋钮。Cityengine沿着中心线每前进一小段距离，就按当前的横断面参数生成一段几何，然后拼接到一起。

因此，道路规则库的核心结构可以拆成三层：

• 入口层：定义规则如何响应道路段（street segment）的基本属性，比如是否为主干道、是否生成人行道。
• 横断面层：决定路面由哪些带状结构组成，每个带子的宽度、高度、材质、贴图映射方式是什么。
• 细节层：负责车道分界线、路面箭头、斑马线、路灯等点缀物，这些通常用条件函数和循环阵列来实现。

2.2 为什么选择“属性驱动”而非“几何直建”

早期我写道路规则时走过弯路，喜欢把每一条路都直接“写死”，比如直接指定路面宽度8米、人行道两边各3米。项目刚开始看起来很顺利，但一旦遇到路网里同时存在主干道、次干道、支路的情况，就不得不复制出三套几乎相同的规则，然后手改每个文件里的参数。维护成本直线上升，改一个路缘石高度要同时改三个文件，漏改一个就是灾难。

后来我彻底转向属性驱动设计。思路是：道路的几何形态不直接在代码里写死，而是通过attr（属性）暴露出来，每条道路段可以通过Cityengine的属性面板单独设置参数。同一条规则文件，套在不同等级的道路上，表现完全不同。

这里我建议用一套辅助的“等级映射”策略。在规则库里定义道路等级（如level=1表示快速路，level=2表示主干道，以此类推），然后在规则开头用一段逻辑，将等级映射到具体的宽度、车道数、人行道宽度等参数。实际使用时，只需要给每条道路段设置一个等级值，其他什么都不用管。

这样做的好处很多：一是项目后期调风格只需要改规则顶部的映射表；二是美工同事不懂CGA也能通过属性面板调出想要的效果；三是规则库的通用性大幅提高，换一个项目只需要重新调整映射关系，不需要重写规则。

2.3 工具链与配套资源的选型

Cityengine的道路规则库不是孤立运行的，它依赖一整套工具链和资源库：

• 数据准备：ArcGIS Pro或QGIS，用于处理路网数据。直线型shp文件是最理想的输入，但实际项目中往往需要先做拓扑检查，特别是处理断头路、重叠线。
• 贴图资源：高质量的沥青、人行道砖、路缘石贴图。我习惯用Substance Painter或者直接从纹理网站获取PBR材质，在规则里通过texture函数调用。
• 辅助建模：交叉口细节有时需要额外做几个可复用的模型组件，比如红绿灯、路牌、消防栓，用FBX格式导入作为prefab。
• 测试环境：Cityengine自带的viewport足够日常预览，但大规模场景建议先在局部路网测试，确认规则无误后再铺开到全域。

关于版本，目前Cityengine 2022以后的版本对PBR支持很完善，强烈建议用PBR材质流程，效果比旧版的标准材质好很多。如果你的项目预算有限，可以用Cityengine的免费试用版做规则开发，但正式出图还是需要正版授权。

3. 核心规则库的框架拆解与实践

3.1 从零开始：Road规则的基本骨架

一套标准的道路规则库，入口通常长这样（我简化了实际代码，保留核心结构）：

@StartRule Street --> generateLanes(streetWidth, laneCount, sidewalkWidth) generateCrosswalk() generateStreetLight(lightDistance) generateRoadMarking()

这里的关键是把生成过程拆成可独立维护的模块，每一个模块对应一个函数。这种写法的好处是，如果你只想改斑马线的样式，只需要进入generateCrosswalk函数内部修改，不会影响其他模块。

再看generateLanes函数的核心逻辑：

generateLanes(width, lanes, sideW) --> laneWidth = (width - 2*sideW) / lanes tiledLane(laneWidth, lanes, sideW) tiledLane(laneW, n, sideW) --> case n > 0: Lane(laneW) tiledLane(laneW, n-1, sideW) else: Sidewalk(sideW)

可能你已经注意到，这里用了递归的方式生成多条车道。CGA里没有传统编程语言的for循环（实际上有，但递归更常见也更好控制），所以你需要习惯用“递减+终止条件”来模拟循环结构。n从车道数开始，每生成一条车道就减一，直到0为止，然后生成两侧的人行道。

如果你直接跑这个规则，会遇到一个问题：路面是平的，两侧没有人行道边界。这时候需要给每条车道赋予高度偏移和材质：

Lane(w) --> set(shapeL, w) set(shapeH, 0.15) texture("assets/road/asphalt_01.png") setupProjection(0, scope.xy, 2, 2) projectUV(0) extrude(0.15)

这里set(shapeL, w)将当前shape的宽度设置为车道宽，extrude(0.15)把路面挤出15厘米的厚度，这样道路和两侧的地面就有了高差，视觉层次立刻不一样了。贴图部分用了setupProjection和projectUV，作用是让沥青纹理沿路面方向重复平铺，而不是整条路面只贴一张拉伸模糊的大图。

3.2 车道分界线与道路标线的生成技巧

道路标线是中国项目里最容易忽视又最出效果的部分。GBA规则里生成标线有两种思路：

一种是把标线作为独立的几何体叠加到路面上方，优点是控制精细，缺点是会多一层几何面，场景面数上涨明显。另一种是用贴图来实现标线，把车道线的纹理烘焙到沥青贴图的alpha通道里，性能好，但灵活性差，改车道数时要重新画贴图。

我个人的选择是：分道线用贴图，停止线、斑马线、箭头用几何实体。分道线通常不变，一张带虚线纹理的贴图轻松搞定；而斑马线、停止线的位置和数量在不同交叉口差异很大，用几何规则按参数动态生成更灵活。

车道线纹理的生成方法：

LaneLine --> texture("assets/road/lane_line_dashed.png") setupProjection(0, scope.xy, 1, 3) projectUV(0) extrude(0.02)

注意这里的setupProjection参数：1是水平方向每米重复一次，3是纵向每3米重复一次，这样一条3米长的虚线分道线就出来了。如果要改成实线，把贴图换成实线版本即可。

斑马线的实现思路也不复杂：

Crosswalk(width) --> s(1, 0.02, 0.5) t(0, 0.03, 0) primitiveCube() color("#FFFFFF") i("null")

斑马线由多条平行的白色矩形条带组成，所以依然用递归或循环生成，每次沿道路横向偏移一个固定距离。矩形厚度给0.02米，防止闪烁（Z-fighting）。

3.3 交叉口的自动衔接处理

交叉口是道路规则库中最容易出问题的地方。两条路相交，路面边界如何顺滑交接？人行道如何绕过转角？车道线如何汇合？

Cityengine的street network本身提供了一定的交叉口处理能力，它会自动创建小块（intersection shape），我们可以为这些小块编写专门的规则。通常的做法是：

Intersection --> case hasIntersectionType(1): NormalizeIntersection() else: UnmarkedIntersection()

NormalizeIntersection负责生成带斑马线、停止线、导流岛的标准交叉口，UnmarkedIntersection则生成无标线的简单交叉口。两种模式通过属性切换，适应不同等级道路的交叉组合。

实际项目中，交叉口最容易出问题的点是路缘石转角半径。城市道路规范里，主干道交叉口的路缘石转弯半径一般在15到25米之间，快速路更高。这个数据直接写死在规则里肯定不行，因为每条相交道路的等级不同，转弯半径也应该不同。我通常的做法是：从相交道路中取最高等级，再乘以一个系数得到转弯半径。

turnRadius = max(r1.level, r2.level) * 5

规则里会自动计算这个半径，然后生成一段圆弧路缘石。这样一套逻辑下来，无论是主-主相交还是主-次相交，路口都能自动匹配合理的转弯参数。

3.4 地形自适应：道路贴合起伏地面的实现

做山地城市项目时，最常见的问题是道路悬空或陷入地形。Cityengine生成的默认道路是水平直线，如果地形起伏大，必须让道路自动适应地面高度。

CGA中处理地形贴合有三种方式：

• 采样地形高度并平移：用terrainHeight函数获取某点的地形高度，然后对照道路shape的中心点高度做差值，最后通过translate把道路整体降到地表。
• 通过规则自带的“地形贴合模式”开启。Cityengine的道路规则在生成时有一个选项叫“Align To Terrain”，它会自动让生成的道路shape贴合地形起伏。
• 将道路底面的材质设为“地形透明”，利用地形的垂向穿透，让道路看起来像是嵌在地表里。

但三种方式的优缺点截然不同。第一种控制最精细，适合高精度项目，但计算量大，规则复杂；第二种最省心，但需要道路底面比地面稍微高一点点，否则路缘石和地面的衔接处会有裂缝；第三种性能最好，但只适合俯视视角为主的项目，近距离看会露馅。

我自己惯用的是第二种加第三种混合：大区域用“Align To Terrain”模式，同时在规则里给路缘石下方多加一条0.3米高的“地基”体，掩盖缝隙。遇到项目需要高精度地形配合时，再切换到第一种来精细控制。这条经验帮我避开了很多次项目评审时被问到“为什么路和地之间有条缝”的尴尬。

4. 实操过程与关键功能实现详解

4.1 一套可直接上手的道路规则库代码

下面我给出一套简化但完整的道路规则，你可以直接复制到Cityengine里跑起来。这套规则涵盖了：多车道生成、双向分道线、两侧人行道、路缘石挤出、简易交叉口斑马线。

@StartRule Street --> print("Generating street width: " + streetWidth) generateRoadShape() attr streetWidth = 12 attr laneCount = 2 attr sidewalkWidth = 3 attr laneMarkingStyle = "dashed" generateRoadShape --> tiledLane(streetWidth, laneCount, sidewalkWidth, 0) tiledLane(totalW, lanes, sideW, currentLane) --> case currentLane < lanes: LaneUnit(totalW, lanes, sideW, currentLane) tiledLane(totalW, lanes, sideW, currentLane + 1) else: SidewalkUnit(sideW) LaneUnit(totalW, lanes, sideW, idx) --> laneW = (totalW - 2*sideW) / lanes s(laneW, 0.15, 10) t(0, 0, 0) i("builtin:cube:unit") color("#3d3d3d") // 分道线：在最中间车道的左侧边界生成虚线 case idx == lanes - 1: LaneLineMarking() LaneLineMarking --> s(0.15, 0.02, 10) t(-0.075, 0.1, 0) i("builtin:cube:unit") texture("assets/road/lane_line_dashed.png") setupProjection(0, scope.xy, 1, 3) projectUV(0) SidewalkUnit(w) --> s(w, 0.3, 10) t(0, 0, 0) i("builtin:cube:unit") color("#a0a0a0") texture("assets/road/sidewalk_tile.png") setupProjection(0, scope.xy, 1, 1) projectUV(0) @StartRule Intersection --> case hasIntersectionType(1): Crosswalk(streetWidth)

这段代码虽然精简，却涵盖了道路规则库最核心的几个模式：递归生成车道、条件判断边界、贴图投影、交叉口入口处理。你可以在此基础上扩展绿化带、公交车道、非机动车道等功能。

4.2 关键参数的含义与计算方法

规则库里有一堆参数，每个参数选择是否合理，直接决定最终效果。这里挑几个我使用频率最高的参数讲讲计算思路。

• streetWidth（道路总宽度）：它是机动车道、非机动车道、绿化带、人行道宽度的总和。常规的城市支路建议12到16米，主干道建议40到60米。在规则里我一般不直接暴露这个参数，而是让用户输入“道路等级”，由等级映射表自动计算总宽度。这样既减少用户操作，又能保证道路宽度符合城市道路设计规范。

• laneCount（车道数）：注意不是所有车道都是机动车道。如果项目里有公交专用道或非机动车道，建议把车道数拆成motorLaneCount、busLaneCount、bikeLaneCount三个参数分别处理，程序里再求和得到总车道数。

• sidewalkWidth（人行道宽度）：规范上城市道路人行道最小宽度一般不得小于2米，条件受限时也要保证1.5米以上。在规则库里参数默认值建议设为3米，满足绝大多数项目需求。

• 路缘石高度：这其实是很多新手不会注意的参数。城市道路路缘石高度通常在0.1到0.15米之间，但如果你要做人行道与路面高差超过0.2米的场景，需要确保人行道下面有地基结构，否则远看会有“悬空感”。

如果你想在规则里检查参数合理性，可以用函数：

@StartRule Street --> case streetWidth < 6: print("Error: streetWidth is too small") Street() else: generateRoadShape()

这样在参数设置不合理时，Cityengine的控制台会直接给出警告，避免生成一堆明显错误的几何。

4.3 实际项目中的规则库组织方式

单套道路规则放到真实项目中往往不够用，我习惯把道路规则库组织成下面的目录结构：

/road_rules/ ├── assets/ │ ├── textures/ │ │ ├── asphalt_01.png │ │ ├── lane_line_dashed.png │ │ ├── sidewalk_tile.png │ │ └── curb_stone.png │ └── models/ │ ├── streetlight.fbx │ └── traffic_light.fbx ├── rules/ │ ├── street_main.cga │ ├── street_secondary.cga │ ├── intersection.cga │ └── common.cga └── data/ └── road_network.shp

common.cga里放公共函数和常量，比如全局的颜色定义、材质定义、常用计算函数。三个道路规则文件分别对应不同等级的道路，这样职责清晰，你只需要修改对应等级的规则文件即可，不会误伤其他等级。

另一种组织方式是用CGA的import功能，把公共函数拆到独立文件里，用import common导入。这种方式适合团队协作，避免多个人同时修改同一个文件造成大量冲突。我在团队项目里采用的就是common.cga放公共函数、每个道路等级一个独立文件的方式，效果很好。

4.4 道路附属设施：路灯、树木、交通标牌的批量生成

道路不只是路面和标线，路灯、行道树、交通标牌才是让场景有生活气息的关键。CGA里生成这类沿线等距分布的对象，核心是递归加位移。

路灯的生成逻辑可以写成：

StreetLight(dist) --> case dist <= 0: NIL else: t(0, 0, dist) i("assets/models/streetlight.fbx") StreetLight(dist - lightInterval)

这里lightInterval是路灯间距，按照常规城市道路标准，路灯间距一般在25到40米之间。规则开头设置一个初始的dist为道路总长度，每次递归沿道路方向移动一个间距，然后放置路灯模型，直到剩余距离不足一个间距为止。

行道树同理，只是间距需要根据树种冠幅调整，一般6到8米一棵。要特别注意的是，行道树位置一般位于人行道外侧，靠近路缘石的绿化带内，所以需要在放置时做一次横向偏移：

Tree(dist) --> case dist <= 0: NIL else: t(0, 0, dist) t(3.5, 0, 0) i("assets/models/tree_01.fbx") Tree(dist - 8)

这里的3.5米是绿化带中心到道路中心线的距离，根据实际断面调整即可。这些附属设施全部规则化之后，一条一公里的道路，路灯、树木、标牌的数量和位置全部自动算好，节省的时间非常可观。

5. 常见问题与排查技巧实录

5.1 路面贴图拉伸或模糊不清

这是出现频率最高的问题，几乎每个人都遇到过。现象是：一条长道路生成后，沥青纹理被拉伸成一条条长斑，或者纹理密度完全不对。

检查顺序如下：

• 是否调用了setupProjection？如果没有，默认的UV映射可能是按全局坐标平铺的，路面的长宽比会直接导致纹理拉伸。
• setupProjection的第一参数（纹理通道）是否正确？我习惯用0号通道作为基础色贴图，但如果你的PBR材质包含法线贴图和粗糙度贴图，需要额外设置1、2号通道的投影。
• 水平方向和垂直方向的参数代表什么？以setupProjection(0, scope.xy, 2, 2)为例，意思是沿x方向每2米重复一次贴图，沿y方向每2米重复一次。如果你把道路长度方向当成y轴，但贴图是横向重复的话，参数需要做对应调整。
• 如果项目里道路宽度远大于贴图尺度，单张纹理会被放大得模糊，需要根据实际车道宽度调整重复次数。

我通常的做法是：沥青纹理按1米×1米平铺，混凝土人行道按0.5米×0.5米平铺，这样道路近景细节充足，远景也不会因为纹理过密导致性能下降。

5.2 交叉口处出现破面或重叠几何

交叉口是规则库调试的重灾区。典型表现是：两条路交会的区域出现重叠路面、贴图闪烁（Z-fighting），或者人行道互相穿越。

这类问题通常源于交叉口shape的几何生成和道路段本身的几何生成是两套逻辑，宽度不一致时就会重叠。排查思路：

• 确认交叉口的边界，是否完全覆盖了所有相交道路的路面范围。如果路面宽度大于交叉口shape尺寸，路面会伸出交叉口区域产生重叠。
• 检查相交道路的人行道宽度参数是否一致。如果一条路的人行道宽3米，另一条宽2米，交叉口的人行道边界就会出现台阶式错位。
• Cityengine里有一个“Intersection Boundary”属性，可以通过它调整交叉口生成多边形的大小。手动微调这个值往往能解决大多数重叠问题。
• 实在不行，在交叉口规则里生成一块覆盖原有几何的“地面盖子”，用同色材质遮住破面，虽然不算完美解决方案，但应付远视角渲染足够。

5.3 道路悬空或陷入地形

前文提到过地形贴合问题，这里再补充一个细节。Cityengine处理地形贴合，实际上是把道路中心线的节点投影到地形表面上，然后在节点之间插值形成贴合的三维曲线。如果路网数据里节点过稀，在地形起伏大的区域，道路就会表现为一条直线穿透山体或悬挂在半空。

解决思路很简单：在导入路网之前，对shp线数据进行加密。在ArcGIS Pro或QGIS里，用“Densify”工具把线上的点加密到每5米一个点，路网的拟合精度就会大幅提升。另一个思路是在Cityengine导入数据时勾选“Sample Terrain Elevation”选项，让每个节点自动采样地形高度。

还有一点容易被忽略：地形本身的三角网精度。如果地形TIN很粗糙，即使道路节点加密，贴合效果也不好。建议在高差起伏区域对地形做局部细化，或者使用更高分辨率的DEM数据。

5.4 规则报错信息看不懂

Cityengine的报错信息对新手极不友好，经常是一大段英文堆栈。我的经验是：

• 看到“missing texture”优先检查贴图路径。CGA中路径是相对规则文件所在目录的，文件移动后极易失效。
• 看到“division by zero”检查除法运算的除数。最常见的情况是车道数为0，或者人行道宽度为0导致分母为0。
• 看到“Operation not supported”检查当前shape类型是否匹配。比如在面状物体上执行extrude没问题，但在点状物体上执行就会报错。
• 看到“Unknown identifier”检查变量或函数名是否拼错。CGA对大小写敏感，命名不一致会让编译器无法识别。

如果报错信息实在看不懂，最快的办法是二分法排查：每次注释掉一半的规则体，看报错是否消失。不断缩小范围，通常能在几分钟内定位到问题所在。

5.5 常见问题速查表

6. 规则库性能优化与大规模场景适配

6.1 面数控制：细节不能杀死帧率

道路规则库一旦铺开到城市级场景，面数失控是必然的。一条两公里长的道路，如果每10米放一棵树、每1米生成一段路缘石，整个城市的面数会迅速爆炸。

性能优化的核心原则是LOD（Level of Detail），按距离分级加载。Cityengine里可以通过“LOD使用不同精度的规则”来实现。近距离使用精细规则（路灯、斑马线全生成），中距离使用简化规则（只保留路面和标线），远距离甚至可以直接退化为一条带纹理的简单面片。

CGA里判断LOD的典型写法是：

Street --> case lod == "far": FarStreet() case lod == "mid": MidStreet() else: FullStreet()

lod变量由Cityengine在渲染时自动切换。同一套规则在不同LOD下生成不同精度的几何，是城市级场景不卡顿的根基。

另外，注意控制extrude的段数。CGA中圆角、弧线通过segment（分段数）来控制精度，每段增加都会翻倍增加面数。城市级场景里，道路路缘石的弧形不一定需要64个分段，8到12个分段的效果在远看几乎没有区别，但面数节省却极为可观。

6.2 多细节层次的策略：宏观路网优先

实际项目里一条路做多精细不重要，重要的是几十条道路放在一起时能不能统一调度。我的建议是：先快速生成全城的低精度路网，将场景跑通，确认所有道路的位置、走向、宽窄比例没有问题后，再局部替换为高精度规则。

例如，初始导入路网后先使用如下极简规则，生成全城的“路网底图”：

@StartRule Street --> s(10, 0.1, 10) i("builtin:cube:unit") color("#555555")

这种极简模式生成的面数极低，十几条道路同时生成也毫无压力。等布局确认完毕，再对关心的重点路段启用完整规则库。很多项目最终成果只需要重点区域精细，周边区域粗模足够，这种“精细+粗模”混合策略是最实用的。

6.3 烘焙与实例化：几何转资产

当你确定某一段道路规则生成结果不再改动时，可以考虑将生成的几何“烘焙”成FBX或直接导出为3D模型资产，然后以实例（instance）方式复用。实例化能极大降低GPU压力，因为同样的一棵树、一盏路灯，在显存中只需要存一份，通过变换矩阵摆放到不同位置。

Cityengine里对实例化有内建支持，在生成规则时给模型添加instance关键字即可。不过需要注意，实例化只适用于完全相同的模型，如果你希望路灯有随机角度或颜色变化，就不能使用普通实例化，需要改用随机化参数生成不同变化的实例组合。

6.4 性能测试流程建议

每次调整规则库后，我建议按以下流程做性能测试：

1. 语法检查：编译通过，无错误。
2. 小范围生成：在100米×100米的区域内随机生成5条路，观察生成速度和内存占用。
3. 镜头旋转：在视口内快速旋转镜头，观察是否出现明显的延迟卡顿，定位面数主要集中在哪类物体上。
4. 大范围压测：铺开整个路网运行一次，记录总耗时和生成几何面数。
5. 渲染测试：用离线渲染模式输出一张大图，检查纹理细节和边缘质量。

如果第3步出现卡顿，优先检查最耗面数的组件，通常为繁复的人行道铺装细节、高分段的路缘石弧线、过多的场景树。逐一降配后再做性能回归测试。

7. 规则库的扩展与二次开发思路

7.1 让道路规则适应不同风格规范

国内外的道路设计规范并不统一，即使同在国内，不同城市的细节也不一样。一套优秀的道路规则库应当支持通过配置文件快速切换风格。

我习惯在common.cga里维护一个“风格配置文件”，把所有跟地域规范相关的参数集中到一个哈希表中，例如：

attr style = "CN" getRoadWidth(level) = case style == "CN": case level == 1: 60 case level == 2: 45 else: 25 case style == "EU": case level == 1: 36 case level == 2: 24 else: 15 else: 20

这样，只需要修改顶部的style变量，整个路网的横断面参数就会统一变化。这个思路在做多城市对比、方案展示时特别有用，你能在几分钟内让同一套路网从“中国城市风”切换成“欧洲小镇风”。

7.2 接入GIS数据的自动化流程

道路规则库最强大的用法是和GIS数据联动。在ArcGIS Pro中准备一个包含道路等级（LEVEL）、车道数（LANES）、道路名称（NAME）等属性的shp要素类，导入Cityengine后，这些属性就是规则可以直接获取的内置变量。

我习惯在规则里通过属性读取来精细控制：

@StartRule Street --> print("Current street: " + streetName) generateByLevel(level)

这时你会发现，每一条路都天然携带了它的属性信息，规则库只要按属性分配横断面参数即可。整个流程已经高度自动化，你甚至不需要逐条选中道路手动调整属性，只需要保证GIS数据里的属性字段准确即可。

7.3 动画与动态展示方向

道路规则库不仅能出静态模型，也能为动画场景服务。你可以在规则里加入时间维度参数，比如让交通灯按固定时间改变颜色，或者让车辆沿道路自动寻路行驶。虽然在Cityengine原生场景里做复杂动画不如专业DCC软件便捷，但用于方案汇报和展示已经足够。

我更推荐的做法是：把道路规则生成的几何导出到Unity或Unreal Engine中，再配合引擎的交通系统做动态模拟。Cityengine导出的道路带有正确的UV坐标和材质命名，这对接引擎非常关键。导出的FBX文件中命名规则要规范，我在规则里严格使用语义化命名（如RoadSurface、Sidewalk、Curbstone），方便引擎里的自动化调用。

7.4 从个人小工具到团队共享资产库

最后谈谈团队协作。道路规则库不应该只属于某一个人，它应该成为团队共享的核心资产。建议搭建一个简单的版本管理流程：

• 规则文件统一存放在版本管理系统中，每次改动用commit记录变更原因。
• 贴图资源和FBX模型单独归入素材库，规则中通过相对路径引用，不写绝对路径，方便换机器拉取。
• 每一次成功的项目配置，沉淀为“模板场景”，下次新项目直接复制模板，替换GIS路网数据即可。

我在团队里还推行了“规则库CR流程”：任何人对规则库的修改，必须生成一组前后对比渲染图，说明改动内容和原因，然后提交给其他人评审。这样可以避免某个人改坏规则后，其他同事隔了几天才发现问题而无法排查的窘境。

8. 项目落地中的经验与扩展建议

8.1 用好底图数据是成功的一半

坦白讲，道路规则库写得好不好，只占项目成功的一半，另一半取决于输入路网数据的质量。我在多个项目里反复验证：一份拓扑干净、属性完整的shp路网数据，配合一套中等质量的规则库，产出效果远好于一份糟糕数据加上顶级规则库。

所以开工前请务必花时间检查数据质量：

• 有没有断头路、重复线段、交叉口处未打断的线？
• 属性字段是否齐全，道路等级、宽度、车道数是否合理？
• 线方向是否一致（这会直接影响道路左侧和右侧的人行道生成）？
• 高程数据是否和路网对齐？

如果数据质量不过关，哪怕规则库再强大，生成的结果也会出现各种奇怪的问题。而且CAD和GIS软件里看着正常的数据，到Cityengine里经常出现意外，提前排查能省下大量调试时间。

8.2 多版本对照与参数化方案汇报

用道路规则库做方案汇报时，我常用一个技巧：准备3到4套不同的参数方案，分别代表不同的规划思路。例如方案A是“宽路稀网”导向，方案B是“窄路密网”导向，方案C是“公共交通优先”导向。每次汇报只需要切换一套参数，整个城市的道路形态就变了，配合属性面板实时联动展示，决策者和规划师都能直接看到数值变化带来的空间形态影响。

这种参数化汇报方式的优势在方案评审中非常明显。传统CAD图纸无法直观感受路网密度与街区尺度，而规则库的参数联动让参会人员能即时体验“车道数从4改到6”对城市街道空间的影响，沟通效率提升了不少。

8.3 常见误区提醒

最后说几个我见过的常见误区，希望能帮你避开：

• 误区一：道路规则库就是写代码，不需要懂规划。实际上不懂道路设计规范，车道宽度、转弯半径、路口渠化全凭感觉写，生成的模型外行看着花哨，内行一看就知道不对。
• 误区二：规则越复杂越好。复杂的规则意味着难以维护、难以调试、容易出错。一套清晰简单的规则，远比一套绕来绕去的高级规则更实用。
• 误区三：只做道路不做周边。道路是骨架，但如果旁边的建筑、绿地、地块没有响应道路规则，整个场景依然缺乏整体感。优秀的项目都是把道路规则和地块划分、建筑生成规则统一设计。
• 误区四：急于求成，没有预留足够的调试时间。道路规则库的调试往往比写规则本身耗时更长，不要低估交叉口、地形贴合、纹理映射这些细节的难度。

我在实际项目中体会最深的一点是，道路规则库不是一次性的产物，而是需要在多个项目中持续迭代的资产。每一次项目都会遇到新的规范、新的地形、新的表达需求，规则库就在这一次次磨炼中逐渐成熟。上面分享的框架、代码和避坑经验，都是我踩过不少坑之后沉淀下来的。如果你也正在搭建自己的道路规则库，希望这些内容能帮你少走一些弯路，把精力省下来去处理真正有挑战的创意部分。

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