1. 用“无限”两个字做测试前提：我究竟想验证什么

某头部科技公司最近发布了他们的“无限世界生成器”。官方演示视频里，一个黑发少年角色驾驶着一辆带垂直推力的飞车，沿着日落时分的金融区街道低空掠过，镜头持续拉升，街区的霓虹灯和玻璃幕墙连绵不断，整个画面没有出现任何加载卡顿。我第一反应是这剪辑做得真干净，第二反应是如果这玩意儿真能实时生成，那它和传统开放世界的地图系统根本不是一回事。所以我决定实际拿一套内测权限跑一跑，不按演示模板走，而是自己造一个偏离开发者预设的测试场景。

大多数人理解的“无限地图”，是以传统开放世界游戏为代表的那种预先烘焙好的大地图：所有建筑模型、贴图、碰撞数据都提前做好，客户端只是按玩家位置从硬盘往内存里做流式加载。这套逻辑的极限是硬盘容量和制作成本，地图再大也有边界，制作组花几年填出来的内容密度也几乎不可能浩瀚到“逛不完”。而这次发布的无限世界生成器走的是另一条路：世界不是被制作出来的，而是被生成出来的。程序里跑着路网规则、街区布局模型和建筑模板库，当你朝某个方向移动时，它才开始现场拼接下一块街道。

我最终定下的测试目标，不是“打开工具看它能不能跑”，而是想验证三个更实际的问题：第一，外部角色模型能不能顺利放进这个生成世界，资产管线的开放程度到底有多高；第二，高速载具和生成中的城市物理系统能否兼容，尤其是当移动速度远超步行时，世界生成速度还跟不跟得上；第三，也是最重要的判断：密集高楼场景会不会戳穿“无限”这个牛皮。以下所有内容，都是我这套测试路线下的真实体验。

1.1 为什么要用“角色模型+飞车”来测

只逛城市只能证明生成器能渲染出一个好看的街景，不能证明它真的可以被创作者使用，更不能证明它扛得住压力。我选择把“无限世界生成器”和“外部资产导入”放在一起测，本质是在模拟一个真实创作流程：创作者很少只用生成器自带的原始资产，他们会导入自己的角色、自己的载具、自己的道具。如果导入一个带骨骼动画的角色就出问题，那这套工具对独立创作者的价值就会大打折扣。

飞车则是一个压力测试器。传统游戏里你可以开车，但速度通常被限制在每小时一两百公里，因为地图流送和物理系统需要时间反应。而飞车的垂直推力和夸张加速能力，可以把移动速度拉到步行的数十倍，世界生成速度跟不上就立刻露出马脚。大都会里的高楼又会不断遮挡视野，镜头俯仰旋转频繁，LOD系统和场景流送会因为镜头抖动剧烈而暴露出过去被小心隐藏的瑕疵。简单说，这个测试组合就是在逼它说出真话。

1.2 我的测试路线与判断标准

进入工具后，我先把所有画面质量选项拉到最高，关闭动态分辨率压缩，也不开启垂直同步。城市主题选择上，我没有用官方推荐的“奇幻小镇”模板，而是指定了一个“金融区+滨水区+旧城区”的混合现代都市主题。然后我设定了一条固定路线：从旧城区的窄街出发，上高架跨越一条水面，穿过一片中央公园式的绿地，最后迫降到金融区主街。

我全程记录三类现象：一是肉眼可见的世界生成断层，比如道路突然消失、建筑从地面“长出来”或者墙面纹理变化突兀；二是飞车高速行驶时的帧率波动，尤其注意它在穿过密集建筑群时的最低帧数；三是角色模型是否穿模、是否原地抖动、是否被载具物理误伤。我自己这套机器配置是中高端游戏台式机，内存64GB，固态硬盘，显卡为上一代旗舰型号，这个配置能跑出的结果不等于所有设备上的通用成绩，但足以反映这套生成器的基本压力承受水平。

2. 把黑发少年塞进驾驶座：导入链路里的三个麻烦

先谈角色模型导入。我以为这一步会像往一般建模软件里导入FBX那样简单，结果第一步就被教育了。这个无限世界生成器的编辑器确实允许导入外部模型，但它的默认设置里藏着不少“坑”，如果直接接受一切默认参数，成品会非常诡异——我的黑发少年角色进来之后，站在原地永远维持着待机呼吸动作，两条手臂不规则摆动，像在跳某种很新的机械舞。

2.1 文件格式与动画文件的取舍

我最初用的是带完整骨骼动画的FBX文件，里面包含待机、走路、跑步、攻击等多段动作。生成器识别出了这些动画，并且在导入后默认把角色绑定到了一个“通用人形骨骼模板”上，于是角色永远处于播放动画的状态。最可怕的是，当飞车起步之后，角色依然在驾驶座上做站立姿态的待机动作，头和头发都透出车顶。

解决方案是放弃动画，只导入静态网格。具体做法是在导入面板里关掉动画导入开关，同时勾选“烘焙T-Pose”，这样角色会以标准站立姿势被固定下来。配置文件里对应的参数大概是这样的：

"actor_import": { "source": "./models/black_hair_character.fbx", "import_options": { "enable_animation": false, "bake_tpose": true, "uniform_scale": 1.0, "auto_retarget": "" } }

auto_retarget这里我特意留空，因为一旦填入系统推荐的骨骼模板，它又会把我关掉的动画系统重新激活，角色又会被拉回那个诡异的“站姿驾驶模式”。

2.2 缩放比例与驾驶座锚点

第二个麻烦是缩放比例。导入之后，角色模型只有飞车轮胎的三分之一高，整个人缩在座椅里，像个手办。原因是这个引擎的资源单位和我建模软件里用的单位不一样，FBX文件内记录的是“1个网格单位=1厘米”，引擎默认却按“1个网格单位=1米”来读，所以模型被缩小成了原来的百分之一。

解决方式有两种：一是在导入设置里把单位换算从“米”改成“厘米”；二是直接在模型缩放参数里填入0.01，反向补偿。改完之后还要处理角色锚点，把它拖进驾驶座挂点。飞车这个载具本身带一个名为“driver_socket”的挂点，但锚点默认在模型脚底，如果直接把角色丢进去，他会有一半身体陷在座椅下面。需要把角色锚点从脚底提高到髋部高度，并用旋转参数对齐方向盘方向，这样坐姿才看起来正常。

2.3 碰撞体策略

第三个麻烦，也是我一开始完全没想到的：默认情况下角色模型自带一个胶囊碰撞体。这个碰撞体在地面步行时没问题，但放在飞车里就灾难了。飞车启动后，角色会和座位产生持续的物理接触推力，车在加速时会感觉像顶着一个软木塞，角色模型反复被压进座椅又弹出来，画面抖动得很厉害。

我的最终处理办法是直接把角色的碰撞体模式设为“无碰撞”，只保留渲染层，让飞车穿过角色时不产生任何物理反馈。由于黑发少年只是坐在驾驶座上当乘客模型，不需要参与任何物理交互，这个方案最稳。如果你的角色模型需要下车走动，再给他单独配置一个自定义碰撞胶囊体即可，只是要注意别和载具座位冲突。

3. 城市是怎么“变”出来的：路网、楼群和地标

把角色安置好之后，我才真正开始认真观察这座被生成出来的大都会。为了研究它的生成逻辑，我在一个路口停了三分钟，把镜头拉到上帝视角，盯着下方街区的生成过程看。我看到的不是一块一块“贴图突然出现”，而是像有人在用积木快速拼装：先是地面有了一条道路的轮廓，然后道路两侧出现地块白线，接着建筑体块在那个地块上被“挤”出来，最后外墙挂上玻璃纹理和广告牌细节。

3.1 路网与街区骨架

这套生成器的路网生成逻辑，基本可以概括为“主干道先画骨架，次干道填充肌理”。它先根据城市主题生成几条宽阔的主干道，形成一个粗略的网格，再在网格内部细分出次干道，最后切割出大小不同的街区地块。我用俯瞰视角观察时，发现这些街区既有规则的矩形地块，也有因主路斜向穿过而产生的三角形、五边形地块，这种不规则感让城市显得比较真实，没有规划软件的“方格本”味。

每个街区还会被贴上用途标签，比如商业区、住宅区、公园、水体、公共服务设施。生成时不同用途决定建筑模板的选择：商业地块通常生成玻璃幕墙高楼，住宅地块是低层砖房和联排，公园地块则用树丛和步道填充。这个标签系统也影响了交通流量和路边装饰的密度，比如商业路段的广告牌明显密集。不过偶尔也会出现荒诞组合——我亲眼看到一栋二十层的玻璃大厦旁边紧贴着一棵巨大的榕树，树冠直接塞进楼体里，这种违和感说明区域标签和植被放置逻辑之间还缺少一层冲突检测。

3.2 建筑体量分层技法

高楼不是凭空出现的，它有一个明显的“从低模到高模”的替换过程。同一个建筑在远处看只是一个简单的灰盒子，只保留轮廓比例和大致屋顶形态；当镜头拉近到一定距离后，灰盒子会在一两个帧内被替换成拥有真实窗户分割和玻璃材质的完整高模；再近一点，底层商铺的招牌和入口门头细节才会被加载出来。

这套LOD分层策略本身不新鲜，但如果观察点移动速度过快，问题就来了。开飞车高速掠过街区时，很多建筑来不及完成“灰盒子→高模”的过渡，镜头刚到眼前才突然“爆出”完整的墙体和招牌，视觉上像城市在不停打喷嚏。后来我在设置里搜索LOD相关参数，把高模替换距离从默认的50米拉到200米，现象明显缓解，但代价是显存占用上升了约三分之一。

3.3 城市主题与“地标夹具”

最有意思的是这个生成器对城市主题的响应方式。我原本以为它会用一个统一的神经网络从头生成整座城市，结果观察下来更像是在组合“模板库”。比如“金融区”模板会尽可能生成细长高耸的玻璃塔，并且给它们配上蓝色或绿色窗格材质；“旧城区”模板则会生成低层砖楼、狭窄步道和有年代感的招牌样式。

生成器还会从模板库中为每个街区挑选一个“标志性建筑”，放在街区中轴线上作为视觉锚点。我蹲在路口仔细观察时发现，某栋类似历史钟楼的建筑在一片现代高楼中显得极其突兀，但它确实被生成器指定为这个街区的“文化中心”。这个设计很像游戏关卡编辑器的“预制体摆放”逻辑：如果说整座城市是一场拼图，那这些地标就是拼图里被事先打印好的几个关键图块，其他建筑都是围绕它们临时拼的。

4. 在AI街区开飞车：速度、帧率和物理的账

角色和城市都准备好了，接下来才是真正好玩的部分。这辆飞车的物理模型其实是一套普通载具系统换了一层皮肤：有驱动力、有转向、有悬挂反馈，但额外加了一条垂直升力曲线，模拟反重力悬浮。这个设计反而挺好，因为它在物理碰撞层面上的规则和普通车一致，不至于出现完全无法预判的运动轨迹。

4.1 我把速度拉到了多少

我分三档测试了世界生成器在不同速度下的表现，结果差异相当明显。第一档是常规地面车速，大约每小时120公里，这个速度下世界生成完全无感，所有街区、建筑和树木都提前出现在视野范围内，我甚至能在高速行驶时从容观察路边细节。第二档是高速巡航，大约每小时420公里，开始偶尔能察觉到远处楼群有低模延迟，但很快会被补齐，不影响行驶。

第三档则非常疯狂——我把飞车升力调到最高，速度上限拉到每小时780公里。在这个速度下，前面几公里的城市看起来是正常的，但两侧和后视镜方向会短暂出现“空白世界”，朝侧边看会发现远景还没有生成，像站在一个正在被铺开的地毯上。好在几毫秒内缺失区域就会被生成器补齐，很少出现完全开进虚空的情况。我把三档的实测稳定性和帧率数据整理成了表格：

需要提醒的是，这几组数据是在我自己这台机器上测出来的，显卡负载、内存读写速度不同结果会有浮动。但整体趋势是明确的：世界生成的瓶颈不在生成能力本身，而在渲染管线能不能及时把新生成的模型送入视野。

4.2 开飞车和开地面车最大的区别

飞车给城市带来的最大变化是观察角度。地面车只能沿街道前进，镜头被两侧高楼夹住，生成器只需要处理前方和头顶一小块区域。飞车一旦拉起升力升到几十米高，视野就完全打开了：我能同时看到前方几十栋建筑的屋顶、背后的街区和下方道路，相当于一次性要求系统把更大面积的城市生成出来并完成渲染。

实际升到大约80米高度俯瞰，城市像一块被精确切割的巨大棋盘。商业区的高楼密度让我终于理解了为什么这套生成器对显卡压力这么大——每栋楼都要实时生成并渲染，整个金融区同时出现在画面里时，三角形的顶点数量轻松突破百万级。我用帧率监控软件记录到，在低空掠过密集楼群时的最低帧数只有约45帧，虽然还在可玩范围，但和空旷区域的120帧相比差距悬殊。

4.3 碰撞的快乐与代价

飞车的速度和物理碰撞组合在一起，产生了很多有趣的意外。速度过快时直接穿墙进入某个建筑内部，几乎是我的日常操作。这个生成器对建筑碰撞体的策略比较简单：地面建筑的碰撞体只在靠近地面的一定高度内启用，飞车飞到高层位置后就会直接穿过楼体，像幽灵一样穿行在摩天楼内部。

更离谱的是，我全速冲刺时曾经撞出过城市边界。飞车越过城市边缘后，前方会出现一片灰色虚空，然后系统把我连人带车重新拉回到最近的合法地块上，大概是自动回城机制。这种体验很难评价——作为测试者我觉得“能撞出世界”这件事本身就很有趣，但从一个成熟产品的角度看，边界处理还是过于粗暴了，至少应该加一层雾或者山脉遮挡。

5. 一路踩坑：墙面穿模、街区重影和加载雾

连续高强度跑图之后，我攒下了一批问题，基本可以分成四类，每一类都找到一个可以复现的操作路径。下面的内容，是我按“问题表现—排查过程—解决方案”记录下来的实测笔记。

5.1 世界断裂：两个街区之间的拼缝

在某个高架出口位置，我遇到了一个特别显眼的问题：道路在两块街区交界处出现错位，左侧道路比右侧高了将近半米，飞车开过去时车身明显顿了一下。我起初以为是物理碰撞物摆放错误，后来把镜头拉远观察，发现整个街区的建筑风格也出现了突变——这边是红色砖房，过了拼缝突然变成全玻璃幕墙。

排查后的结论是：这两个相邻区块使用了不同的“区块生成种子”，导致路网标高和建筑风格不连续。我的解决方式是进入生成参数面板，把区块顶部的“共享地图形状”选项打开，并要求相邻区块在生成前同步一次路网标高数据。打开之后重新生成了一个测试城市，拼缝问题消失，道路标高至少在区块交界处能保持连续。

5.2 街区重影：远方楼群出现“重复脸”

高速飞过一片高楼区时，我发现远处好几栋大厦长得几乎一模一样，像站成一排的商品展示柜。这不是巧合，而是远距离低模状态下，生成器为了提高性能复用了少量“远景楼型”，远看时不同建筑之间的差异被抹掉了。

解决方法有两种：一是把“建筑多样性”参数从默认的60%调到90%，代价是每个新街区的生成耗时明显上升；二是提高远景建筑模型的细节阈值，让低模状态就包含更多不同的形态轮廓。两个方法我都试了，第一方法对重影问题的改善更明显，但加载世界时的CPU占用率会稳定提高不少。

5.3 加载雾：建筑像烟花一样在面前“爆出”

这是所有问题里最影响沉浸感的一个。当飞车以400km/h以上的速度穿过市中心时，远处的建筑一直是灰白色的低模盒子，直到距离拉近到大约30米内，它才瞬间切换成完整的高模形态。因为建筑密集，这种切换会在视野里同时发生很多次，看起来就像整个街区在我面前连续“爆炸”出一批完整建筑。

我一开始以为是显卡来不及渲染，后来查看性能监控发现CPU反而是瓶颈，是CPU生成新建筑数据的耗时太长，导致渲染端拿不到足够细节。我把高模切换距离从默认的50米拉到200米，效果立竿见影，只要能提前生成好数据，切换就不会出现在脸上。

5.4 角色姿势混乱：黑发少年在车里摆出大字型

这个问题最让人哭笑不得。有一次我正常驾驶时突然瞟了一眼驾驶座，发现黑发少年双臂呈大字型张开，头部旋转了90度，看起来像被风吹散骨架的人偶。原因是之前关掉的动画系统在某个载具物理事件中被重新激活，系统把角色强行推进了一个默认的人形动画状态，而我关闭的只是角色自身的动画导入，没有关闭“全局动画重定向”。

解决办法是在世界生成器的全局设置中，把“载具乘客动画重定向”选项彻底关闭。这个选项默认会让乘客的骨骼绑定到载具运动的惯性姿态上，对我的静态模型来说完全是多余的功能。关掉之后，角色就老老实实坐车了。

6. 逛完全城，我对“无限世界生成器”的真实判断

最终，我开着飞车把这座城市里里外外逛了个遍。从旧城区的砖石小巷到金融区的玻璃森林，从河岸的日落到商业区的午夜霓虹。平心而论，这套无限世界生成器已经不只是演示层面的玩具，它在很多场景下已经接近可以商用的程度，但我对“无限”两个字也有了更清醒的认识。

所谓无限，本质上是模板的组合空间确实可以无限枚举：生成器不需要手动画出每一栋楼，只需要在框架确定的前提下不断挑选和组合模板库里的建筑、道路、植被和地标。局部看，每一条街都足够丰富；但全局看，如果生成距离拉得足够远，建筑的重复模式一定会周期性出现。这不是bug，是算法成本限制。

从实用角度说，现阶段最适合它的场景是游戏关卡预演、电影虚拟预演、建筑可视化这类“不需要精确叙事”的场合。如果你只是想快速搭一个能开飞车逛的大城市，它能帮你省掉建模团队几个月的工作量；但如果你想在某一栋楼里安排一个剧情触发点、让某个NPC在特定公寓出现，那就会很痛苦，因为世界是随机的，手工布局能力非常弱。

最后再分享一个我的实操小技巧：如果你也打算拿这套生成器做类似的压力测试，我建议你先把画质从最高档降一档，关闭动态阴影，再把飞车最高速度限制在400km/h以内。这样既能保住流畅度，又能看到大部分有趣的生成细节。等跑通了基本链路，再慢慢把画质和速度拉回极限档，否则很容易出现“世界还没崩，显卡先崩”的情况。黑发少年最终在金融区最高的那栋楼顶停了下来，我关掉了引擎，看着脚下这座刚被算出来的城市，还挺想知道它在另一个种子参数里会长成什么样。