128 个视角
山谷里的 16 个地点,每个地点 8 个镜头朝向,按玩家看到的方式测量。
巴西·巴伊亚,1887
全屏测量,1920×1080
历史记录里的 60 FPS 来自 9 月 26 日,窗口为 1280×720,树林只有今天的三分之一。山谷变大了,屏幕升到 1080p,10 月 5 日的新内容又把帧率压到了十几帧。
先测量,再动手
山谷里的 16 个地点,每个地点 8 个镜头朝向,按玩家看到的方式测量。
每次只改一项,并总与基准交替测量,以消除漂移。收益以毫秒计。
物理、脚本和 GPU 分别测量:在做任何改动之前,瓶颈就已显现。
第二轮测量没有改动任何设置,结果复现了第一轮:广场为 4.8 对 5.3 FPS。
按影响大小排序,全部实测
树林、灌木层和景观绿化加起来有 4670 万个三角面,而按距离裁剪几乎覆盖了整个山谷。
Tripo 模型默认开启了背面绘制。关掉它,照片里看不出任何变化。
四级级联、最远 180 u 的阴影,每帧要重画 370 万个三角面。
单个 tick 最长 22 ms 的脚本,让 Godot 每帧最多运行 8 个 tick。在广场,游戏一度跌到 5 FPS。
它每帧都重画整个山谷,却只是为了一张 170 像素的地图。
全屏下的边缘平滑,耗时几乎与太阳阴影相当。
在教堂里正对着墙壁时,游戏仍在绘制墙外山谷的 890 万个三角面。
显卡只以 60 W 中的 17 W 运行,被系统限制。这不是游戏的错,却会放大其他所有问题。
从点击到迈出第一步
缓存缺陷会让屏幕在每次搭建山谷时冻结 19 秒。已修复,结果完全一致。
一次在菜单后面,用于飞越镜头,另一次在点击开始游戏时。这是交付之后的工作。
地形网格和碰撞每次打开游戏都用 GDScript 重新生成。
村民、野兽和室内场景在进度条走满之后才生成,还会卡顿近 8 秒。
在 Tripothon 版 Build 9B 中
海岸网格改为按边缘缓存:山谷的搭建时间从 48 秒降到 32 秒。
每帧最多 3 个 tick。低于 20 FPS 时,游戏会变成慢动作,而不会越拖越卡。
太阳阴影只到 70 u,使用 2 级级联,地形和丝带不再投射阴影,并用 FXAA 取代 MSAA。
树木减半,林中开出 12 片独立的空地,每片都有一棵独特树种的标志树(或一座房子)、几块石头,以及一条通往道路的土路。
地图不再每帧重画山谷:它是一张固定的图片,玩家标记叠在上面。
菜单不再构建 3D 山谷:一段用 LTX 生成的循环手绘飞越画面衬在祭坛画后面。这段 36 秒的过场动画就是本页的开场。
拖动分隔线
之前
之后
之前
之后
之前
之后
版本数据
| 指标 | 之前(实测) | 之后(实测) |
|---|---|---|
| 最差视角的 FPS | 5.3 | 18.0 |
| 中位视角的 FPS | 12.9 | 28.9 |
| 最佳视角的 FPS | 30.1 | 42.8 |
| 每帧三角面数(中位数) | 5.72 百万 | 1.77 百万 |
| 每帧物理 tick 数(中位数) | 4.6 | 2.1 |
| 山谷搭建时间 | 48 s | 29 s |
| 加载:从选择语言到能够行走 | ≈ 97 s | ≈ 35 s |
测试机器:戴尔 G3,GeForce GTX 1660 Ti Max-Q,1920×1080,128 个视角。
Build 9B · B 组,已锁定
使用箭头 键盘方向键