游戏场景生成与编辑

小舟第一次打开引擎，把昨天生成好的那座"江边楼台"拖进场景视图——结果它像一块巨型广告牌横躺在半空中，比远山还大十倍，还是侧着倒下去的。他反复缩放、旋转、拖动，花了四十分钟才让它"勉强站直"，而旁边的扁舟只有指甲盖大小。小月看着屏幕说了一句本章要回答的全部问题："我们是不是从一开始就没说清楚，这个场景到底长什么样？"

这句话点破了一个常见误会：很多人以为"场景生成"就是"让 AI 画一个背景"。不是的。一个能走进去、能跑的场景（scene），本质是一份被严格约定过的工程文件——它规定了有什么东西、放在哪、多大、用什么材质、站在哪儿能看到什么、跑起来要花多少性能。本章要回答三个问题：第一，一个场景由哪些要素构成，我们凭什么说它"好用"？第二，怎么把一句自然语言需求，变成机器和人都看得懂的规格表？第三，这些资产怎么真正落进引擎，而不是落进"打不开的文件夹"？顺着这三问，小舟会为《春江花月夜》短片搭出"夜江场景"的初稿——这也是本章的作业。

7.1场景的五块拼图：地形、建筑、道具、光照、氛围

先建立一个总印象。把场景想成一台话剧的舞台：演员走的地板是地形，两侧的布景和后墙是建筑，台上摆的桌椅茶杯是道具，头顶那几盏灯是光照，而观众感到的"闷热""清冷""雨夜感"是氛围。少了任何一块，舞台都会露怯：地板缺了演员就悬空，灯缺了所有人都像纸片，氛围缺了整个画面会像没上色的线稿。

为什么要专门"拆成五块"来讲？因为 AI 工具是按资产类型分工的。天空盒生成器只擅长生成 360° 的环境图；三维生成器只知道"我拿到了一个物体的描述"；材质工具输出的是贴图，不是几何。你不先把需求拆成"我到底要哪几类资产"，就会拿着一个工具去要它给不出的东西——这是初学者最常见的浪费。第 1 章讲过的"提示词四要素"里，输出格式是最容易被忽略的一环；在场景任务里，"输出格式"就具体成了"输出的是不是这一类资产"。

下面逐块说明，并且每一块都给出"A 类工具缺口"——也就是 AI 最不擅长的那一小段，这正是你未来最值钱的手艺所在。

地形：场景的"地基"

地形（terrain）负责回答"脚踩在哪里、视线在哪里被挡住"。它包含两部分：高度场（地面起伏，通常用一张灰度图表示"每个点多高"）和地表材质（草地、沙石、泥土的分布）。水面比较特殊，它既像地形（有高度、反射天空）又像道具（有波纹、有倒影），工程上一般单独处理，本章在 7.5 节专门讲。

生活类比：地形就是房子的地面平整度——地不平，家具怎么摆都别扭。课程情境：小舟的"夜江"里，地形不能是"一座山加一片平地"，而要有一条从远山切到江岸的缓坡，让镜头从岸边推向江心时有自然的高差。AI 工具缺口：现成的文生三维工具只生成"一个物体"，不生成"一片几平方公里的地形"；地形必须靠程序化算法（7.4 节）或地形编辑工具生成。

建筑：画面的"骨架"

建筑（architecture）承担两个职责：一是体量——在远景里提供剪影和层次，让画面有"远近"；二是形制——在近景里提供文化信息，让观众一眼认出"这是哪里的、哪个年代的"。第二点在后文思政部分会重点展开，因为它最容易出错。

生活类比：建筑像一幅画的构图骨架，它先于细节存在。课程情境：小江希望"楼台"出现在画面右三分之一处、半掩在柳树后——这不是美术偏好，而是规格：位置 (x, y, z)、朝向角、高度、占地范围，都可以写成数字写进清单里。

道具：故事的"标点符号"

道具（props）是场景里那些"可以被拿走、被使用、被特写"的小物件：一盏灯、一条船、一张琴、一摞书。它们体量小，但对叙事极其关键——道具是导演用来提示观众的标点：逗号、顿号、感叹号。

课程情境：《春江花月夜》里的"扁舟"就是核心道具。它小，但它是"人"的替身——船停在水上，观众就会自动补上"有人在这里看月亮"。这类"小而不重要"的资产，恰恰是 AI 生成器最擅长、单价最低的一类，也是最适合练手的起点。

光照：决定"像不像"的一半

光照（lighting）包含三个可调的东西：光源（太阳、月亮、灯）、方向与强度、以及全局光照设置（环境光从哪里来、阴影怎么衰减）。一个被反复验证的经验是：同一个模型，换一套光照，观感差距可以大于换一个模型。这也是为什么很多看起来"很高级"的场景，其实模型面数并不高。

课程情境：夜江场景的主光源只能是月亮。这意味着光的方向要统一（所有景物的受光面朝同一侧）、强度要压得低、色温要偏冷，而楼台窗内的一点暖光成为画面里唯一的暖色——这个"冷暖对撞"就是全片的气氛支点。

氛围：最便宜、也最容易做砸的一层

氛围（atmosphere）是天空、雾、色调映射与粒子（水汽、飞萤、落花）的总和。它最便宜——一个天空盒加一层雾就能让画面"换季"；也最容易做砸——因为它是全局层：改一次雾的浓度，所有资产的颜色都要重新对一遍。

生活类比：氛围像给照片加的那层统一滤镜；滤镜能让同一个房间 morning 和 midnight 判若两地。课程情境：如果天空盒是冷蓝、雾是中性灰，而楼台却是暖黄、扁舟是青绿，那台上所有东西都在"各自发光"，观众的第一反应是"假"。所以本书建议一条硬规矩：先定氛围，再生成资产，并把色板写进清单。

7.2场景好不好用：三个评价维度

"好看"是一个无法验收的词。工程上必须把它拆成可检查的指标，才谈得上改进。场景的可用性可以拆成三个维度，它们互相拉扯，构成一个经典的"不可能三角"：视觉统一、玩法动线、性能预算——你很难同时把三个都拉满，成熟的做法是"明确谁优先、谁让步"。

维度一：视觉统一（风格一致 + 构图合理）

视觉统一说的是：场景里的所有东西，看起来是不是出自同一个世界。它包含内容与形式两层——风格（写实/水墨/低多边形/像素）、比例（人的身高与门的高度是否匹配）、色彩（是否共用一套色板）、细节密度（远处的石头和近处的石头精细程度是否合理）。

要诚实说明一件事：截至本书编写时，检索范围内并没有见到针对"AI 场景风格统一性"的公认量化标准。行业里更常见的做法是用工程手段替代标准：例如天空盒生成工具 Skybox AI 提供 30 余种风格包（Style Pack）预设，让同一套场景的天空、光照保持一致；三维生成侧的 Seed3D 2.0 则通过统一的 PBR 生成模型来减少多步骤之间的"级联误差"（每一步都偏一点，最后整体跑偏）。

对课程作业，本书给出一套可操作的"土办法"，比追求量化标准更管用：一份参考图集（3–5 张）+ 一个色板文件 + 一套材质命名规范。所有资产生成前先过一遍参考图集，生成后对照色板看一眼——统一性靠"减少随机"，不靠"事后调色"。

维度二：玩法动线（可通行、看得懂、走得通）

场景不只是被看的，还是被"走"的。即使你的作品是短片而不是游戏，动线（玩家/镜头在空间中的移动路径）也决定观众能不能看懂。动线包含三件事：起点与终点（从哪进来、到哪结束）、可通行性（哪里能走、哪里是墙）、引导与遮蔽（用什么吸引注意力、用什么挡住不该看的东西，行业里叫"掩体/遮挡"）。

这里有一条来自真实项目的宝贵经验：校验必须先于实例化。检索到的多个 AI 关卡生成项目都遵循同一个流程——先让模型生成布局数据，对布局做严格校验（确保从出生点到钥匙、门、出口确实存在一条通路），校验通过之后才真正把物体实例化进引擎。其中 WATCH MY ESCAPE 的工作流更进一步，坚持先设计解法路径、再写地图 JSON：先想清楚"怎么算通关"，再倒推地图长什么样。

课程情境：小舟把这条经验移植到短片里——先定 6 个镜头的机位与运动路径，再让楼台、扁舟、柳树的位置服务于这些机位（哪几个物体必须在画面里、哪个物体必须挡住画面外的东西）。这样搭出来的场景是"给镜头用的"，而不是"摆着好看的"。

维度三：性能预算（面数、贴图、LOD、绘制调用）

性能预算（performance budget）是三个维度里最容易被忽略、却最"硬"的一个：它像一个月的伙食费，花超了就要挨饿。场景的性能开销主要来自四笔账：三角面总数（模型精细度）、贴图内存（每张 2K/4K 贴图都要占用显存）、细节层级（LOD）是否分层、以及绘制调用（draw call）的次数（引擎每提交一次"画这个材质的一批物体"就是一次调用）。

关于绘制调用，本书要坦白一个"事实底座"里的空白：检索范围内没有拿到 2026 年的 draw call 预算标准数字，所以这里只讲原理不给具体配额——合并材质、减少材质数量、对重复物体做实例化，是降低绘制调用的三个基本手段。同理，具体的面数预算也要看目标平台与引擎版本，本书在 7.6 节给出一份行业常用的参考区间，并明确标注它的适用条件。

7.3把一句话变成一张清单：大语言模型与场景规格表

回到小舟的困境。他说的是"搭一个夜江场景"，而引擎需要的是"这 47 件资产，各自的编号、类型、位置、朝向、尺寸、面数上限和材质"。这两者之间隔着的不是"美术水平"，而是一次翻译——把自然语言需求翻译成结构化数据。

好消息是：这次翻译恰好是大语言模型（large language model, LLM）最可靠的一种用法。坏消息是：它只有在被"约束"时才可靠。本节讲清楚这个约束怎么做。

核心模式：一句话 → JSON 规格 → 校验 → 建场景

把检索到的多个可运行项目放在一起看，会发现它们不约而同地长成同一个样子：自然语言描述关卡 → 由模型生成 JSON 格式的场景/布局规格 → 对 JSON 做 schema 校验与游戏规则校验 → 解析进引擎，构建出可玩的场景。所有项目反复强调的关键词是同一组：严格的输出契约、schema 校验、解析失败后的重试、强制结构化输出而不是解析自由文本。

为什么这个顺序不能换？用一个生活类比就懂了：它像装修。你不会对施工队说"给我弄个温馨点的客厅"，然后指望他们自己拿主意；你会先出一张施工图——哪里是承重墙、插座几个、柜子多宽。施工图就是规格表：它把"温馨"翻译成可以核对的数字。而"先校验再施工"对应装修里的验线：如果图纸本身自相矛盾（门开在承重墙上），越早发现越省钱；等到墙都砌完了才发现，代价就是全部重做。

六个真实项目，一个共同答案

下面这张表是检索范围内可查到的、把"LLM 生成场景"真正做成了工具的项目。它们的做法差异很大，但收敛到同一批工程要点上——这些要点就是你可以直接抄进自己作业的模板。

学术侧也有两条对应的证据链：其一，一篇 2026 年 2 月发表的会议论文《Hybrid Procedural World Generation Using Generative AI》用一个网页应用把模型产出的结构良好、清晰的 JSON 数据（描述地形、任务叙事与物品特性）直接集成进游戏引擎；其二，一篇题为《Knowledge-Conditioned, Single-Pass LLM Synthesis of Executable Unity Game Scenes》的预印本证明了"带 schema 约束"的收益——在带 schema的条件下，用一个两段式管线（先产出引擎特定的中间表示 JSON，提示词明确要求"只输出合法 JSON，不要多余文本"，再由编码提示词从中间表示生成引擎脚本）就能合成可执行的场景，而论文同时编目了若干编译错误类型，提醒我们"能生成"与"能编译"仍是两回事。

规格表长什么样：字段设计与一份可用的模板

字段设计有三个原则：机器能校验（用数字、枚举、布尔值，不用形容词）、人看得懂（字段名直白，附单位）、不重不漏（每件资产只归属于一个类别，每个相机只引用已存在的资产编号）。下面这张表把字段分类说明。

下面是一份可直接使用、也可以直接复制去改的 JSON 骨架。注意它通篇只有数字、枚举和短标识符，没有一句抒情描写——抒情的部分（"月色清冷"）被我们留在了提示词里，因为那是给人看的。

{
  "scene_id": "chunjiang_night_river_v1",
  "version": 1,
  "engine": "Unity 2022 LTS",
  "units": "meter",
  "extent": { "x_m": 320, "z_m": 320 },
  "terrain": {
    "generator": "fbm", "seed": 20261009,
    "octaves": 5, "lacunarity": 2.0, "persistence": 0.5,
    "max_height_m": 18, "water_level_m": 0
  },
  "atmosphere": {
    "time_of_day": "night",
    "palette": ["#0b1b33", "#1d3557", "#6d8fae", "#e8d5a3", "#f4a261"],
    "fog_density": 0.008
  },
  "assets": [
    { "id": "sky_001", "type": "skybox", "format": "HDR",
      "prompt": "夜空，满月高悬于江面上方，薄云，远处山影，冷蓝主调" },
    { "id": "terr_001", "type": "terrain", "max_tris": 40000 },
    { "id": "water_001", "type": "water", "level_m": 0,
      "material": "M_Water_Night", "max_tris": 200 },
    { "id": "bld_001", "type": "building", "name": "临江楼台",
      "position": [-6, 0, 22], "rotation_deg": [0, -18, 0],
      "size_m": [9, 7, 6], "max_tris": 8000, "lod_levels": 3 },
    { "id": "prop_001", "type": "prop", "name": "扁舟",
      "position": [4, 0, 30], "rotation_deg": [0, 12, 0],
      "size_m": [3.2, 0.6, 1.1], "max_tris": 1200, "lod_levels": 2 },
    { "id": "prop_002", "type": "prop", "name": "灯笼",
      "position": [-3, 2.4, 23], "size_m": [0.4, 0.5, 0.4], "max_tris": 400 }
  ],
  "budget": { "triangles_total": 120000, "texture_mb": 180 },
  "cameras": [
    { "id": "cam_01", "position": [0, 1.6, 40], "look_at": "prop_001" }
  ]
}

这份提示词里有三处值得单独说明。第一处是"只输出一个 JSON 对象"——这不是矫情。模型默认喜欢"先寒暄、再解释、最后给结果"，而解析脚本只认第一字符到最后一字符都是 JSON 的文本；一旦多出一句"好的，这是你的场景："，整段解析就失败了。第二处是"不要自行发明字段"——模型很乐于帮你加字段（比如自己发明一个 mood_level），而多出来的字段会让校验脚本报错或者被悄悄忽略，两种结果都不好。第三处是"无法映射时写进 notes"——留一个合法的出口，比逼着模型硬编要诚实得多。

拿到 JSON 之后：四道校验

规格表生成出来只是开始。真正决定成败的是接下来这四道关，它们全部是确定性检查——不看画面、不靠感觉，只跑脚本或对照清单：

1. schema 校验。字段名对不对、类型对不对、必填项有没有缺、枚举值是否在允许范围内。这一关解决"机器读不懂"的问题。
2. 数量与目录约束。资产条数是否超过上限、同类资产是否过量（"树上长了 200 个灯笼"）、是否有重复 id。这一关解决"机器读得懂但读出来是灾难"的问题。
3. 玩法规则校验。用你的相机路径当作"动线"，检查：路径上的每个机位是否能看见主体、路径有没有穿过建筑内部、起点到终点是否连通。这一关解决"能建起来但走不通"的问题。
4. 预算自洽校验。资产条目的 max_tris 求和是否超过 budget.triangles_total；贴图数量估算是否超过 texture_mb。这一关把"性能"从口头承诺变成算术题。

7.4程序化生成：让规则替你"摆"场景

规格表告诉引擎"要有什么"，但"具体长什么样"还有一大块是算出来的，不是画出来的——这就是程序化生成（procedural generation）。它听起来高深，其实你在游戏里早就见过它：为什么《我的世界》的地形可以无限延伸？为什么 Roguelike 游戏的每一局地牢都不一样？因为那些地形与地牢不是美术手工摆的，而是一段带随机数的规则跑出来的。

程序化生成对本章有两重意义。第一，它是"地形"这一要素的主力手段——文生三维工具能给你一栋楼，给不了你一片二十万平方米的丘陵。第二，它提供了一套"约束思维"：好的程序化生成从来不是"随便撒"，而是"在规则允许的范围内随机"。这个思维会让你回到 7.3 节时更明白——为什么规格表要写得那么死板。

噪声地形：把"随机"磨成"自然的起伏"

先做一个思想实验。如果让计算机在地图上给每个点随机取一个高度，你会得到一张碎末状的地面：相邻两个点的高度毫无关系，像电视雪花。这不是地形，这是沙子。自然地形有一个关键特征：相邻的地方高度相近——山不会在你脚边突然变成深谷，它会有一个过渡。

如何在"随机"里注入"过渡"？Perlin 噪声（一种经典的噪声算法）给出了一套优雅的解法，用生活中的东西类比最好懂：

想象一块棋盘，每个格子的角落都插着一支箭头，方向随机（这叫"随机梯度向量"）。现在你要问"棋盘上某个点的地势有多高"，做法是：把该点到它所在格子四个角的方向算出来，与四个角上的箭头各做一次"投影"（点积，可以理解为"这两个方向有多一致"），得到四个数；再按"离得越近、权重越大"的方式把这四个数平滑地插值混合起来（用平滑插值函数 smoothstep，而不是直线插值，这样过渡处不会有生硬的折角）。

于是你会得到一个奇迹般的结果：每个点的高度都是随机的，但相邻点的高度又是连续变化的——既有随机性，又有过渡。这正是"地形"需要的质感。

还有一层认识要建立：Perlin 噪声是伪随机的——它不接受真正的随机源，而是由输入的坐标决定输出。这意味着同一个输入必然得到同一个输出。这不是缺陷，而是功能：你只要记住那个"种子"（seed）数字，就能在三天后、在另一台电脑上，一模一样地重新长出那片地形。

在引擎里的落地方式是前文提过、这里必须点明的一句：绝不每帧采样噪声。噪声计算量不小，正确的做法是启动时一次性把高度图算好、存成一张图或一个数组（例如 513×513 的高度数组），之后每帧只是从内存里读数字。这条纪律的收益是几十倍的性能差——它是新手和专业之间最直观的一条分界线。

波函数坍缩：把"拼接"变成"推理"

第二类算法解决的是另一种需求：我要一片看起来风格统一、但每次都不一样的瓦片地图。比如一片古镇的院落、一座洞穴的内部、一段走廊与房间的组合。这类问题的难点不在"随机"，而在"随便摆出来的东西拼不上"——屋顶瓦片接不上墙，路走到一半撞墙。

波函数坍缩（Wave Function Collapse，缩写 WFC，由 Gumin 于 2016 年提出）是一个名字唬人、思想却很朴素的方法。它的做法是：

1. 准备样本。先给一张"样例图"（或一套瓦片），把它切成许多 N×N 的小图案块（比如 3×3 的像素块）。这就是你的"素材库"与"拼接规则集"。
2. 初始化"可能性"。新建一张空地图，每个格子都列出"所有可能出现的图案"——此时每个格子都处于"不确定态"，这叫它的叠加态。
3. 观察：挑最"确定"的格子先动手。找到"剩余可选图案最少"的那个格子（也就是熵最低的格子），从它的候选里随机选一个，把它坍缩为确定值。
4. 传播：把决定通知邻居。格子一旦确定，它的邻居就"少了一些可能"——凡是与它拼接不上的图案，都要从邻居的候选列表里删掉。删除又会继续影响邻居的邻居，如此链式传播。
5. 重复到最后一格。全部格子坍缩完毕，整张地图就形成了：它与样例图的局部风格一致，但整体布局是全新的。

为什么要"先挑熵最低的"？类比一下：考试时先做最有把握的题。每一道题都代表一个格子的可能性集合；先做最确定的题，就能立刻把相关的题目排除掉一大片选项，越做越顺。反过来，如果先挑可能性最多的格子乱猜，一旦猜错，错误会沿着传播链扩散，最后整张地图崩坏——这就是 WFC 必须处理的"矛盾"问题：当某个格子的候选被删空时，说明已经无解，需要回溯或重启，同时必须设一个"最大迭代次数"的安全阀，避免程序陷入死循环。

泊松盘采样：让物体散布看起来"自然"

地形铺好了，接下来要往上撒东西：树、石头、草丛、灯。最直觉的做法是"每个点随机取一个坐标"——结果是有的地方挤成一团，有的地方大片空白；更糟的是物体会互相重叠、互相穿插，看起来像个 bug。

解决办法叫泊松盘采样（Poisson disk sampling）：要求任意两个点的间距不小于某个最小值，同时整体分布保持随机。它产出的分布叫"蓝噪声"——均匀但不成网格。生活类比：撒种子。你不会把种子撒成棋盘格（那不像自然），也不会随手一扬（那会长成一块块秃斑）；你会尽量让每颗种子之间保持一点点距离。标准实现是 Bridson 算法（常用参数 k=30）；想省算力，用"抖动网格"近似也行——先画规则网格，再把每个点在其格内随机挪一挪。

怎么选：一张决策表

程序化生成的算法不止一种，但它们其实各管一类需求。下面这张图是一份来自实践文档的"算法决策表"，可以直接当作选型速查：看到需求，往右找算法。

7.5资产生产管线：每一类资产有它自己的"生产线"

规格表定好了要什么，程序化算法铺好了地形，接下来是真正的"造东西"环节。这一节的核心观念是：不要指望一个工具包打天下。天空盒、地形、植被、建筑、道具、材质，各自有各自的生成路径、各自的输出格式、各自的验收硬指标。把它们排成一条有序的流水线，比同时开十个网页靠谱得多。

天空盒：一个工具解决的"整个天空"

天空盒（skybox）是包裹住整个场景的 360° 环境图，它同时干三件事：提供天空的视觉内容、为场景提供环境光（间接照明的来源）、以及给水面和金属表面提供反射的"内容"。可以说，天空盒是"氛围"这一要素的技术载体。

它的生成方式已经相当成熟，检索到的最具代表性的工具是 Skybox AI（Blockade Labs）。它把一段文本提示转成生产级的 360° 等距柱状（equirectangular）环境图，秒级完成；官方自述已服务 150 万以上创作者、生成超过 1000 万个天空盒。它的工作流很简单，值得完整记下来：

1. 写提示词描述环境。对场景、光照、时刻、氛围描述得越具体越好——例如"满月之下的开阔江面，薄云，远处山影，冷蓝主调"。
2. 选风格包预设。平台提供 30 余种精选风格包，覆盖从照片级到动漫、数字绘画、低多边形、科幻等取向。这一步是"视觉统一"最省力的抓手：全组用同一个风格包，天空的"画法"就统一了。
3. 生成并环视。数秒出图，可以点击拖拽做 360° 环视检查；不满意就重新生成或微调提示词。
4. 下载。导出选项包括 1K 到 8K（默认 8K，即 8192×4096，最高支持 16K）等分辨率，格式上有等距柱状图、立方体贴图、HDR/EXR、深度图，甚至三维网格格式。
5. 导入引擎。通常拖放即可设为场景的环境或背景贴图。

它的能力边界也要写清楚，免得你在错误的场景里浪费时间：官方明确它不设计用于创建人或动物；当前不能创建"引用其他天空盒"的天空盒来实现连贯的连通空间（该能力在开发中）；也不支持等距柱状视频导出。免费档有明显限制（例如每月约 15 个天空盒，且带水印、按 CC-BY 许可使用），付费档才解锁更高配额、优先速度、商业许可与高级导出。价格、额度与版本在 2026 年变动频繁，使用前请以官方页面为准——这是本书对所有工具类信息的一贯要求。

这段提示词里有两个容易被忽略的细节，值得单独指出。第一是"左右边界需无缝衔接"：等距柱状图是把球面展开成矩形，如果你不强调，生成结果左右两条边往往接不上，环绕一圈时会看到一道明显的"接缝"。第二是"无人物、无动物、无文字"：天空是背景，一旦生成出一只飞鸟或一行文字，它会在环绕时被拉伸变形，成为画面上的笑话。把"不要什么"写进负向提示，是专业提示词与业余提示词最常见的区别之一。

地形、水面与植被：三种"量很大但很便宜"的资产

这三类资产有共同特点：占地大、数量多、但单件面数很低。它们是性能预算里最容易被浪费的地方，也是最容易通过工程手段省下来的地方。

地形由 7.4 节的噪声算法生成高度，再由你手工"雕刻"关键区域——把楼台所在的那块地压平、把江岸修出一条缓坡。这一步的价值在于：算法给出的是"自然"，人给出的是"可用"。程序化地形能长出漂亮的山，但不会主动给你一块能放下房子的平地。

水面看似简单，其实是最容易露馅的一层。技术上它通常就是"一个平面 + 一套专用材质"——面数极低（两三个三角面就够），但材质里包含了反射、折射、波纹法线等一堆计算。它的验收要点有两句话：反射的方向必须与光照一致（月亮在高处，水里的月亮倒影就要相应地长而碎，不能是一轮完整的圆），水面高度必须与地形统一坐标系（否则会出现"船浮在山坡上"这种经典 bug）。

植被的正道是"低模 + 实例化 + 程序化散布"：不要造 200 棵各不相同的高模树，而要造 2–3 种低模树，然后用 7.4 节的泊松盘采样把它们散布出去，并在引擎里以实例的方式重复使用。这样 200 棵树只占一份模型内存——这正是降低绘制调用的核心技巧。

建筑与道具：文生三维真正的主场

建筑与道具是"文生三维"能力最直接的体现：输入一段描述（或一张参考图），输出一个三维网格。这里有三条来自实践的经验：其一，小物件成功率最高——扁舟、灯笼、酒樽这类体量小、结构清晰的物体，生成质量明显优于复杂的建筑群。所以教学与原型阶段，建议从道具练手。其二，建筑要"先定体量、后定细节"——先确认它的长宽高与占地是否与地形、与镜头匹配，再去抠飞檐斗拱；顺序反了，抠得再精细也会被整体比例推翻。其三，参考图比文字更可靠——"唐风楼台"这四个字在不同模型脑中的画面差异巨大，而一张明确的参考图能把这个差异压缩掉大半。

这也顺带解释了第 4 章讲过的那条结论为什么重要：生成出来的网格不一定拓扑干净——可能有非流形边、内部面、反转法线，UV 也常常混乱（重叠、缺失、纹素密度不一致）。所以本章把"导出前检查"（7.6 节）视为管线里的必经环节，而不是可选项。第 4 章已详细讲过拓扑与 UV 的处理，这里只强调它在场景里的特殊后果：一个道具的 UV 乱了，你损失的是一张贴图；一片建筑的 UV 乱了，你损失的是整个画面的统一感。

材质：一次把话说清楚的"表面说明书"

材质（material）决定"这个表面怎么与光互动"。现代引擎使用 PBR（物理基础渲染）工作流，把表面属性拆到多张贴图上、共享同一套 UV 布局。对场景创作来说，只要记住三类贴图的分工即可：

• 基础色贴图（Albedo / Base Color）——纯表面颜色，不含烘焙的阴影与高光。这一条是初学者最容易违反的：如果你把一张"带着好看阴影"的贴图直接贴上去，一旦场景光照变化，那种阴影就会与真实光影打架，看起来"脏"。
• 法线贴图（Normal map）——用 RGB 三个通道编码表面凹凸的方向偏转，不增加多边形就能让平面看起来有细节。砖缝、木纹、瓦楞的"手感"基本都靠它。
• 粗糙度与金属度（Roughness / Metallic）——控制反射的锐利程度与"这是金属还是非金属"。粗糙度 0 相当于镜面，1 相当于完全哑光。

材质环节最大的坑不在生成，而在引擎之间的约定差异。这里有三条必须记住的"翻译规则"：Unity 暴露的是 平滑度 = 1 − 粗糙度（外部导出的粗糙度贴图要用它的反相）；Unity 默认是 Y 轴向上，而 Blender 是 Z 轴向上；Unity 与 Unreal 之间法线贴图的绿通道朝向相反。还有一条更隐蔽的：数字型（非颜色）贴图必须关闭 sRGB 色彩空间，否则你的粗糙度会被引擎按"颜色"再解释一遍，反射全乱。这些差异就是"看起来对"和"真的对"之间的那条分界线。

7.6落进引擎：导入流程、常见坑与性能预算

现在到了最容易翻车、也最有教学价值的一节。资产在生成工具里看起来完美，拖进引擎却"横着躺、大一百倍、颜色发粉"——这不是玄学，而是四个具体的技术原因：单位、变换、轴向、Pivot。把它们一次性讲清楚，你以后能省下大量瞎调的时间。

四个"不可见"的坑

第一个坑是尺度（unit / scale）。检索到的工程资料把它称为"最常见的失败点"：AI 模型常以"任意真实世界尺度"导出，于是出现经典的"我的模型在哪？"问题。最典型的意外是单位不匹配——按米创作的模型，如果导入器假设是厘米，就会大或小 100 倍。Unity 用米，Unreal 用厘米，这句话请你记牢。处理办法：导出前用已知单位（例如约定 1 单位 = 1 米）对照原始人形或立方体参考缩放；在 Unity 里于资产的导入设置中设置缩放因子以匹配场景单位；在 Blender 里应用变换，让 scale 读数变成 (1, 1, 1) 再导出。

第二个坑是"未应用变换"。如果一个资产身上挂着一个 scale 为 (1.0, 1.0, 0.01) 且没有应用过的变换，它"到达引擎时会变成一个煎饼"。原因回到 7.1 节的层级数学：这个缩放会与父级、与引擎的导入设置相乘，结果无法预料。所以规矩是死的：导出前应用全部变换。

第三个坑是轴向（axis）。Blender 是 Z 轴向上；Unity 和 Unreal 是 Y 轴向上。FBX 与 glTF 这类格式会记录轴信息，但不匹配仍会导致模型翻转或旋转——预览中完美的模型可能"横着到达"（这正是小舟遇到的那一幕）。处理办法：在建模工具里把朝向修正为直立并应用旋转，导入引擎后再验证一次；资产应当对齐引擎的前向轴。

第四个坑是 Pivot / 原点。偏离中心的 Pivot"让引擎内放置成为噩梦"：它可能落在世界原点、远在网格之外，或者出现"原点漂移"与包围盒不匹配——这些在渲染截图里完全看不见，却会在场景里破坏放置。正确的做法是按逻辑设置 Pivot：环境资产在地平面上，角色在颈根，机械物体在几何中心。

性能预算：把"会不会卡"变成一道算术题

性能不是一个"跑起来才知道"的玄学问题，而是一份预算表。它的结构很像家庭记账：先定总收入（目标平台能承受的开销），再给每一类资产分配额度，最后逐项核对支出。

先看最直观的一笔账——三角面预算。下面这张图是一次工程资料的汇总，注意刻度是对数的：从几百面到几十万面跨了三个数量级，线性刻度根本画不下。

第二笔账更隐蔽，但往往更早成为瓶颈：贴图内存。工程资料明确指出，UE5 的 Nanite 等虚拟几何技术虽然放松了传统多边形数量的约束，但拓扑、UV 质量、贴图内存与材质复杂度仍然影响性能——而且贴图内存通常比多边形数更早成为瓶颈。这句话值得反复读：很多人把注意力全放在"减面"上，真正的瓶颈却在"你有多少张 4K 贴图"。

第三笔账是 LOD（细节层级，level of detail）。原理很朴素：远处的物体不需要那么多面。同一棵树，近处用高模、中距离用中模、远距离用一张"贴着树形状的纸片"，投影到屏幕上几乎没有差别，开销却差了几十倍。工程资料的建议是明确的：重复出现的资产与远处的资产都需要 LOD 链。

第四笔账是绘制调用（draw call）。它是"引擎向显卡提交一次绘制命令"的动作。这里要特别说明本书的诚实：检索范围内没有拿到 2026 年的绘制调用预算标准数字，所以这里只讲原理，不给配额——合并材质、减少材质数量、对重复物体使用实例化，是降低绘制调用的三个基本手段。注意它与 LOD 的关系：把 200 棵独立的树变成"1 个模型 + 200 个实例"，省下来的主要不是内存，而是调用次数。

7.7关键概念表

本章术语密度较高，这里集中落表，作为复习与查检之用。建议对照你自己的工作文件逐个打勾——每一个词，都对应一次你会在实践里真正遇到的判断。

7.8案例教学：三支团队，一条共同的流水线

接下来三个案例，规模从"三个人一学期"到"上千人的工业化管线"，但你会发现它们踩的是同一块地板：先把需求结构化，再让工具批量执行，最后靠人去检查和判断"对不对"。这个共性，就是我们这个通识课要教给你的东西。

7.9失败案例诊所：三个真实的翻车现场

三个诊断案例，分别对应性能、视觉、文化三类事故。每个都按"症状 → 成因 → 处方"写，处方都可以直接用。

7.10动手实践：搭出你自己的"夜江场景"

本节共四个实践，前三个课堂完成、第四个课后完成，合计约 3 学时（其中实践二可与课后时间合并）。全部实践围绕同一个产出物：一份场景初稿 + 一份结构化资产清单——这既是本章的主线推进，也是课程作业"提交场景初稿与结构化资产清单"的内容。

先给你一张本章的"施工总图"。左侧是俯视布局（示意，非等比），右侧是它对应的清单——清单和布局是同一件事的两种表达：前者给机器读，后者给人看。

🛠 实践一：场景方案设计——让模型帮你写资产清单（40 分钟 · 课堂）

基础

四步走，产出你的 scene.json 与一页布局草图：

1. 写需求。用 100 字以内描述你想做的场景（可以是夜江，也可以换成你喜欢的任何题材，例如"雨夜的旧巷""雪山下的营地"）。必须点名：时刻、天气、主体建筑、一件核心道具、情绪词。
2. 出清单。把 7.3 节的"生成场景规格表"提示词卡复制进对话助手，把方括号里的内容换成你的需求；把表 7-4 的字段清单粘进提示词。要求模型只输出一个 JSON 对象。
3. 做四道校验。对照 7.3 节结尾的四道关：schema 是否合规（字段名和类型对得上吗）、数量是否超上限、相机路径是否走得通、面数预算的加总是否自洽。把不合规的地方改回 JSON，不要只在心里记住。
4. 画布局草图。照图 7-12 的样子，用纸笔或绘图工具画一张俯视图，标出清单里每一件的编号。凡是在图上找不到位置的资产，就说明它其实不该出现在清单里。

提交物：scene.json + 一张标注了编号的布局草图。评分看两条：清单能否被脚本解析；清单与草图是否一一对应。

挑战

给模型增加一个"目录约束"：限定资产条目不超过 12 条、建筑不超过 2 座、同类道具不超过 3 件，并要求它在超限时自己说明舍弃了什么、为什么。你会看到"约束"如何把一份散漫的清单变成一份有取舍的方案——这正是 AI PCG-2D 一类项目里"硬上限"设计的用意。

7.11课程思政：文化准确性与团队劳动

这一节讨论两个容易被回避、却每天都发生在场景创作里的问题：你搭的这个"世界"，对它所代表的文化负责吗？搭它的这些人（包括你自己）的劳动，被诚实对待了吗？我们一条一条说清楚，不给空话。

一、场景是文化载体：准确比"好看"更重要

前面讲过，建筑的第二个职责是"提供文化信息"——观众看到飞檐斗拱、看到服饰形制，就会自动推断"这是哪里、什么年代、谁住在这里"。这意味着场景设计天然是一次文化陈述，它不可能"只是美术"。

检索到的公开争议提供了几条真实教训。一款以日本战国为背景的作品在 2025 年被报道出现"夏季西瓜与春季樱花同框"的季节矛盾，并有学者指出角色服装的形制与其设定身份不符——争议的核心不是"画得美不美"，而是"考据粗疏"。同一批报道还提到：该作品中某处宗教场所可以被破坏，相关神社与协会提出抗议，据报道未获回复、补丁后仍可破坏，事件一度进入该国国会讨论层面。这类后果远超"美术问题"：当场景把一个真实的信仰场所处理成可随意破坏的对象时，它触碰的是许多人的真实感情。

另有一款以敦煌为背景的作品被批评建筑风格"过度中亚化"，专家认为应更具唐风，理由很具体：高昌出土的唐代木构是典型唐制，晚唐时期唐文化仍是该区域的主流文化。也有反驳意见认为，官式与宗教建筑可能更唐制，而普通民宅未必如此——这个反驳本身很有价值：它提醒我们，"考据"不等于"想当然地统一化"，不同阶层、不同功能的建筑本来就有差异。还有一款历史策略游戏在限定内容中，让某座城市国家的角色穿上了另一族群的服饰，争议归因包括"同文化圈模型复用""默认服饰复用"以及长期考据不足；直到第三次补丁，才替换为专门的服饰。

在讲了这些争议之后，必须补上一句平衡的话：网络舆论里也出现了不同国家、不同地区的网友互相指责"挪用"与"双标"的现象——本书不站队，也不认为存在一个"谁有资格做谁的文化"的简单答案。真正有共识的，是方法论层面的那一条：

正面路径是存在的，而且很具体：某款历史策略游戏在 2026 年 3 月推出了三款创作者内容包，涵盖东亚、东北亚与东南亚的服饰与建筑；其中一套是该系列首次由中国创作者主导、官方发行的内容包，作者来自上海。它的考据方法可以直接被我们借鉴：参考文物与古画——例如某类袍服参考了《宣宗行乐图》《明宪宗元宵行乐图》等画作与明代墓葬出土实物；另一种袍服参考了辽代墓葬出土的左衽交领袍。报道的评价是：过去海外游戏处理东方题材常"元素堆得不少，形制却经不起推敲"，而由本国创作者操刀、依据文物古画考据的做法，减少了"文化挪用"与"想当然还原"的担忧。

二、团队劳动：把"效率"和"代价"一起算清楚

第二个话题更贴近日常。这一章反复出现了一组数字：面数差 111 倍、建模省下 478 分钟、这些时间转化成了返工的技术债。请再读一遍最后半句。

行业公开数据里，效率数字往往只算"生成"这一段：三维资产生产从"5–7 天、数千元"到"10 分钟、数元"，听上去像魔法。但同一批检索材料也给出了另一半：普通的手动重拓扑，中等道具约需 30–60 分钟、角色约需 2–4 小时；AI 生成的网格常常"带有数十万个近似均匀的三角面，对渲染、编辑和动画管线而言过于密集"，而纯粹的几何减面"不尊重尖锐特征与部件结构"，达不到生产资产要求的干净拓扑。把这两半合起来看，结论就很清楚：AI 没有消灭这些劳动，它把劳动的位置从"从零开始做"移动到了"检查、判断与重做"。

这个移动有三层含义，都值得你在课程里认真体会：

第一层，谁的工作变了。在盛趣的那个案例里，一个局部场景复刻投入的是"1 名三维艺术家 + 1 位场景设计师 + 半个技术支持"。没有一个是"专职点生成按钮"的岗位——因为按钮太便宜了。人力向三处集中：定义需求、甄别资产、把检查自动化。这和本章 7.3 节讲的"结构层交给脚本、创作层交给人"是同一件事的两面。

第二层，谁的判断不可替代。模型能生成一万座"楼台"，但没有一座能替你回答"这座楼台放在这个镜头里对不对、它的形制对不对、它与小月定的色板和不和"。在本章的作业里，这三问恰好对应三个不同的岗位视角：小舟管"对不对"（技术检查），小月管"和不和"（视觉统一），小江管"该不该有"（叙事必要）。小组分工的价值，不在于每人分到多少活，而在于每人都保留了一块"必须自己判断"的地盘。

第三层，怎么诚实地写效率。检索材料里有一个反复出现的提醒：行业里大量效率提升数据来自企业自称或券商测算，口径各异，不能当作客观测量结果。本书在表 7-10 中为每一条数据都标注了来源性质——这不是走形式，这是通识课要教给你的媒介素养：看到"提效 300%"时，先问三句——口径是什么？分母是什么？算没算返工？同理，在你自己的作业报告里，也请诚实写下"哪部分我用了 AI、哪部分我手工做了、返工花了多久"。一份诚实的报告，比一份漂亮的报告有价值得多。

自测

拓展阅读

• 随查手册：本章用到的三维、天空盒、智能体平台等工具选型见附录 B 工具速查；场景资产涉及文化元素与真人素材时的合规要点见附录 E；把资产生成流程自动化的路径见附录 F。
• Skybox AI（Blockade Labs）官方文档与"2026 完整指南"——天空盒生成的完整工作流、风格包、导出格式与免费档限制；建议亲手生成 3–5 个不同时刻（清晨/正午/黄昏/夜晚）的同一场景天空盒，比较它们对同一批资产观感的影响（本章 7.5 节）。
• Gumin 的波函数坍缩原始项目与讲解文章（2016）——如果你想真正理解"观察—传播"循环，最有效的方式是找一个网页版 WFC 演示，亲手调小网格与样例图，观察它什么时候会失败、什么时候需要重启（本章 7.4 节）。
• 引擎官方文档中的"资产导入与优化"章节（Unity / Unreal / Godot 均有中文页面）——重点读"缩放因子、轴向、LOD、光照贴图"四节；把本章图 7-9 的八项检查与官方文档逐条对照，形成你自己的检查表（本章 7.6 节）。
• 与"场景 AI 生产"相关的行业报告与公开案例（伽马数据、中国音数协、各厂商公开披露）——阅读时请刻意练习一件事：为每一个效率数字标注"来源性质"（企业自称 / 券商测算 / 第三方测量），并追问它的口径与分母（本章 7.8、7.11 节）。
• 文博机构公开的书画与器物高清资源（如各大博物馆的数字藏品页）——这是最便宜也最可靠的"考据参考图集"来源；练习用它作为生成建筑与器物资产时的参考图，并在清单备注里写下具体条目（本章 7.11 节）。