问鼎娱乐场景：AI 3D世界、场景结构与智能空间

在问鼎娱乐场景的生成流程里，只需要输入一句"一间摆放整齐的卧室"之类的描述，Text-to-Scene流程驱动的AI场景生成系统很快就能给出一张床靠墙、衣柜在角落、书桌对着窗户的房间效果图。从渲染图上看，家具摆放的逻辑完全说得通——没有床顶到天花板，没有衣柜卡在门框中间，整体构图甚至比很多人手动摆放的场景还要顺眼。这也是为什么第一次看到问鼎娱乐场景输出结果的人，往往会脱口而出"这已经能用了"。

问题出在"看起来合理"和"能被使用"是两件完全不同的事。摆放合理指的是家具彼此之间、家具与房间边界之间没有明显的视觉冲突，是一个纯粹的构图判断；能被使用指的是一个有体积、有移动需求的角色能不能在这个房间里正常地走动、开门、绕过桌角、从沙发边上挤过去。前者是美术审查的标准，后者是游戏逻辑的标准，二者不是同一套坐标系统在做判断，AI生成的画面好看，并不代表它背后的空间数据也同样"好用"。

技术美术在验收一个AI场景生成的房间时，第一件事往往不是看家具摆得美不美，而是拿真实尺寸去量。一扇视觉上正常的门，实际宽度可能只有一米出头，勉强够一个成年角色的碰撞体侧身通过；一张会议桌，模型高度可能超过门框，这类比例误差在渲染图里几乎看不出来，因为人眼对静态图片里的相对大小很宽容，但一旦放进引擎，用真实单位跑一遍角色控制器，问题立刻暴露。这就是Real-world Scale——生成的几何体是不是按照现实世界的度量单位在搭建，一米到底是不是一米，直接决定了后续所有交互逻辑是否成立。

第二层是Collision，也就是碰撞体的设置。墙壁要真的能挡住角色，不能让人穿墙走位；地板要真的能承载站立和行走，不能出现看得见走不上去的台阶；门要真的能被打开通过，而不是一个纯装饰的洞口贴图。问鼎娱乐团队在测试场景时经常遇到的情况是，AI生成的家具模型本身没有问题，但碰撞体要么完全没有生成，要么用了包围盒简化到失真的程度，导致角色卡在桌子腿之间出不来，或者干脆从楼梯的台阶缝隙里掉出场景。

第三层是Gameplay Space，也就是可玩空间的宽度和高度是否满足角色移动的最低要求。一条视觉上精致的走廊，如果实际净宽只有三十厘米，无论贴图和光照做得多讲究，都没有办法让一个正常体型的角色通过，更不要说做战斗或多人协作场景。这类问题在效果图审查阶段几乎无法发现，只有把角色控制器放进去实际跑一遍碰撞检测和寻路测试才会暴露出来，这也是为什么很多团队会在AI场景生成之后专门加一道空间可用性的复核流程。

问鼎娱乐场景目前能够比较可靠地解决的，是空间关系的合理性和基础比例的一致性——家具不会离谱地悬空或者互相穿插，整体布局符合日常生活的常识。但真实尺度的精确对齐、完整的碰撞体生成、以及可玩空间的验证，目前仍然需要人工复核和引擎内测试来补齐，AI输出更像是一版高质量的空间草稿，而不是可以直接上线的可玩关卡。对创作者来说，真正高效的用法，是把AI生成当作快速搭建空间草稿的工具，同时保留一道专门针对移动性和碰撞的验收环节。

很多人第一次接触AI生成的3D场景，关注点几乎都放在模型精度上——这张桌子的多边形数量够不够高，杯子的高光和材质是不是够真实，场景整体的面数会不会超出预算。这是一个非常自然的关注点，因为面数和材质确实是最容易被截图和渲染图直接展示出来的东西。问鼎娱乐场景在早期做效果展示的时候，也经常被问到类似的问题：这套场景一共多少面，能不能优化到移动端可用。

但真正决定一个AI场景生成结果能不能进入生产流程的，往往不是杯子本身做得多精细，而是这个杯子和它所在环境之间有没有被记录成一种明确的关系——杯子在桌子上，椅子靠着桌子，桌子贴着墙，墙围成了房间。这种关系如果只存在于人眼的观察里，而没有被写进场景的数据结构中，那么这个场景在技术上就是一堆互相独立、位置恰好凑在一起的几何体，而不是一个真正意义上的"房间"。

这就是Scene Graph要解决的问题，也是问鼎娱乐场景在生成之后重点搭建的一层数据结构。一个典型的层级关系大致是这样：房间作为根节点，下面挂着墙体、门、桌子这些主要构件；桌子这个节点下面，又挂着杯子、笔记本这类摆在桌面上的物件；椅子作为独立节点，与桌子之间用"靠近并朝向"的关系连接起来。这种从上到下的Hierarchy，记录的不是几何形状，而是物体之间谁依附于谁、谁的存在依赖谁的位置。

为什么这一层比多边形数量更重要，答案在编辑环节最容易体现出来。如果场景只有几何体，没有Hierarchy和关系记录，那么美术想要把桌子往窗边挪半米，就必须手动把桌上的杯子、笔记本一件一件重新对齐位置，稍有疏忽就会出现杯子悬空或者陷进桌面的情况。而如果场景建立了正确的Scene Graph，移动桌子这个父节点，挂在它下面的杯子会自动跟随移动，相对位置保持不变，这种父子关系带来的连带效果，是纯几何数据完全没有的能力。

同样的道理也适用于替换单个物件。一个原创中世纪村庄场景里，如果只想换掉其中一把椅子的样式，在有清晰关系记录的场景里，只需要替换椅子节点对应的模型，它和桌子的相对位置、朝向关系都会自动保留；但如果场景是一坨没有语义标注的几何体堆叠，团队往往只能整体重新生成或者手动逐个核对每一件家具的位置，这在实际项目排期里是完全不可接受的返工成本。

目前AI场景生成在语义关系的识别上已经能做到基础层级的搭建，比如区分出墙、地板、桌面物件这样的大类，并且建立粗略的父子挂载关系。但更精细的语义，比如两把椅子是不是应该保持对称摆放、某个装饰品是不是该随季节主题联动替换，这类高阶判断，目前仍然依赖人工在Scene Graph基础上做二次标注和调整，AI给出的更像是一份关系草图，而不是最终可以完全信赖的生产数据。对于长期做场景资产的团队来说，一个场景能不能被反复修改、能不能被拆解复用到别的项目里，取决于它有没有留下可编辑的Hierarchy，而不是取决于某个杯子的面数是不是足够精致。

用AI场景生成一整座城市，是目前最容易让人兴奋的应用场景之一。输入几句描述，几分钟内就能得到鳞次栉比的建筑群、纵横交错的街道、甚至连招牌和路灯都摆放得像模像样。第一次看到问鼎娱乐场景输出的大型城市原型时，很多人第一反应是惊讶于生成速度和建筑密度，觉得剩下的工作无非是把这些资产导入引擎、调好光照就能交付。

真正把这类场景放进引擎运行起来之后，最先崩溃的往往不是某一栋楼的模型精度不够，而是整个场景的帧率。原因很简单：一座城市级别的场景可能包含成千上万栋建筑、几十万件道具，如果这些几何体不分远近、不分是否可见地全部实时渲染，再强的显卡也扛不住。这时候暴露出来的瓶颈，不是几何生成质量本身有多粗糙，而是场景有没有做好可见性管理和细节层级管理。

Occlusion，也就是遮挡剔除，解决的是"不渲染看不见的东西"这件事。玩家站在一条街道上，视线被两侧建筑挡住，街区后面那些完全看不到的楼栋，理论上根本不需要提交给显卡渲染。如果AI场景生成只管把建筑摆出来，却没有配套生成遮挡关系数据，引擎就只能老老实实把摄像机视锥范围内的一切都算一遍，哪怕九成的内容根本没有出现在画面里，这种浪费在小场景里不明显，放到城市尺度上会直接把帧率拖垮。

LOD，也就是细节层级管理，解决的是另一半问题：远处的建筑到底需不需要用近处同样精细的模型来渲染。一栋在镜头里只占几个像素的远景高楼，用高精度模型和用简化过的低面版本，视觉上几乎没有区别，但渲染开销可能相差几十倍。问鼎娱乐场景在处理大型城市生成任务时，遇到的真实情况是，AI能够很快地把城市的整体布局和建筑外观生成出来，但每一栋建筑是否自动带有从高精度到低精度的多级简化版本，以及这些版本之间的切换是否自然不闪烁，是完全独立于几何生成质量之外的另一套工程问题。

这也是为什么经验丰富的技术美术在验收AI生成的大型城市场景时，几乎不会把主要精力放在评价某栋建筑的建模是否精致，而是直接打开性能分析工具，看这个场景在实际运行时的绘制批次和帧耗时表现。一个建模粗糙但可见性剔除和LOD分级都做得扎实的城市场景，实际运行体验可能远远好于一个建模精致但没有任何优化的版本，这个结论在大规模场景里几乎屡试不爽。

除了渲染性能之外，大型开放世界场景还有一个经常被忽略的问题，那就是NavMesh，也就是角色和NPC实际能够行走、寻路的区域数据。城市里哪些街道是可以通行的，哪些区域被障碍物完全封死，哪些广场可以让大量NPC同时寻路而不互相卡死，这些都需要专门生成和烘焙寻路网格，而不是简单地假设"路面几何体存在就等于可以走"。如果这一层数据缺失或者生成粗糙，即便场景本身渲染流畅，NPC也可能出现绕远路、卡在障碍物旁边原地打转的问题。对创作者和技术团队而言，评估一个AI场景生成的大型城市是否真正可用，性能层面的可见性管理和细节层级管理，重要程度并不低于几何本身的精细程度，甚至在项目后期往往是决定成败的那一环。