UE5.8 Large World Coordinates 大世界坐标

一次跨星系航行暴露的精度危机

去年秋天，我们组的小李接了一个太空探索 demo。玩家驾驶一艘小型飞船从近地轨道出发，可以跃迁到月球、火星，甚至飞到几光年外的邻近恒星系。美术已经把行星贴图和星空背景做得很漂亮，策划也写好了跃迁航线。小李用 UE5.8 搭了一个原型，初始几天进展顺利：飞船加速、环绕行星、进入跃迁动画都没问题。

他把相机拉到远离行星的位置，手动输入坐标 $(1000000.0, 0.0, 0.0)$，想测试远距离航行。飞船刚抵达这个位置，屏幕就开始出现异常：飞船模型每隔几秒会抖动一次，尾焰粒子变成方块状，仪表盘上的距离读数在小数点后两位来回跳。小李以为是自己手滑改了相机参数，重置了几次，抖动依旧存在。他再把飞船继续往外开，坐标到 $(10000000.0, 0.0, 0.0)$ 时，整个船体开始剧烈抽搐，行星环带像被撕裂的纸片一样上下错动。

那天下午，美术大哥凑过来看了一眼屏幕，沉默半天，问了一句：我们的太空，是不是中病毒了。

小李后来定位到问题根源：IEEE 754 单精度浮点数的尾数只有 23 位，有效数字大约 7 位十进制数。当坐标值变大时，小数部分的表示间隔会指数级放大。在 $x = 10^6$ 的位置，相邻两个可表示浮点数的间隔已经达到了 $2^{-23} \times 2^{20} = 0.125$，也就是 12.5 厘米。粒子系统和顶点动画依赖的位置精度不够，自然就会抖动。在 $x = 10^7$ 时，间隔变成 1 米，飞船模型开始肉眼可见地抽搐。

这个 demo 最后催生了这篇文章。下面把 UE5.8 针对大世界坐标的机制拆开讲，希望能帮遇到同样问题的同学少走点弯路。

单精度浮点的精度墙

先回顾一下单精度浮点数的内部结构。一个 float 占 32 位，其中 1 位符号位、8 位指数位、23 位尾数位。数值可以写成：

$x = (-1)^s \times 1.m \times 2^{e - 127}$

$s$ 是符号位，$m$ 是尾数的小数部分，$e$ 是指数。由于尾数只有 23 位，实际有效数字是 24 位（包括隐含的整数 1），换算成十进制大约是 $24 \times \log_{10} 2 \approx 7.22$ 位。

这个特性直接限制了世界坐标能有多大。UE4 时代的默认坐标类型是 FVector，由三个 float 组成。当坐标比较小时，比如 $(100.0, 200.0, 50.0)$，尾数剩余的精度足够表示毫米级变化。一旦坐标越过 $10^5$ 这个数量级，精度开始明显下降。到 $10^6$ 时，厘米级精度已经保不住。到 $10^7$ 时，米级精度都会出问题。

下面的图展示了单精度浮点在不同坐标量级下的最小可表示间隔。

flowchart LR
    A["坐标量级"] --> B{0~10^2}
    B --> C["间隔约 1.2e-5"]
    A --> D{10^3~10^4}
    D --> E["间隔约 1e-3 至 1e-2"]
    A --> F{10^5~10^6}
    F --> G["间隔约 1e-1 至 1e0"]
    A --> H{10^7+}
    H --> I["间隔超过 1 米"]
    I --> J["顶点抖动 / 粒子错位"]

这个精度墙不是 UE 的问题，而是 IEEE 754 单精度本身的限制。只要还在用 float 存世界坐标，就不可能做出真正的太阳系尺度无缝大世界。要么限制活动范围，要么切换表示方式。

早期项目处理这个问题的方法通常是手动分块。把整个世界切成很多小区块，每个区块内部用相对坐标表示，玩家在区块之间传送。这种方法能撑到几十公里的活动范围，但做不到无缝飞行。玩家从区块 A 飞到区块 B 时，必须触发一次加载或黑屏，体验上有明显断层。

UE5 的 Large World Coordinates 改造

UE5 给出的答案是 Large World Coordinates，简称 LWC。核心思路很直接：把世界坐标和相关变换从单精度浮点改成双精度浮点。双精度的尾数有 52 位，有效数字大约 15 到 16 位十进制数，表示范围大了好几个数量级。

双精度浮点数的最小可表示间隔公式和单精度类似，只是尾数位数变成 52：

$\Delta x = 2^{e - 52}$

在 $x = 10^7$ 的位置，双精度相邻值的间隔约为 $2.2 \times 10^{-9}$ 米，远小于单精度在 $x = 10^0$ 时的精度。换句话说，双精度可以把整个太阳系的坐标都精确到微米级，这对太空模拟类游戏是质变。

UE5 的改造不是简单地把 FVector 改成 double。引擎内部有大量的子系统依赖坐标类型，包括渲染、物理、动画、寻路、网络、音频、关卡流送等。 Epic 的策略是分阶段推进：核心数学类型先改，上层模块逐步适配。

flowchart TD
    subgraph core ["Core Types"]
    end
    subgraph engine ["Engine Subsystems"]
    end
    subgraph platform ["Platform / Hardware"]
        fvector["FVector: double"]
        fmatrix["FMatrix: double"]
        fplane["FPlane: double"]
        fquat["FQuat: double"]
        transform["FTransform: double"]
        render["Render: 裁剪 / 局部坐标"]
        physics["Physics: 局部模拟"]
        anim["Animation: 局部空间"]
        nav["Navigation: 局部网格"]
        net["Network: 双精度序列化"]
        stream["Level Streaming: 大坐标流送"]
        gpu["GPU: float 顶点"]
        cpu["CPU: double 运算"]
        simd["SIMD: 适配双精度"]
    end
    fvector --> render
    fmatrix --> physics
    transform --> anim
    fvector --> nav
    fvector --> net
    fmatrix --> stream
    render --> gpu
    physics --> cpu
    anim --> cpu
    nav --> cpu
    net --> cpu
    stream --> simd

从图中能看到，UE5 在核心数学层全面切换到 double。FVector、FMatrix、FTransform、FPlane、FQuat 这些类型在 LWC 模式下使用 64 位浮点。上层子系统则在 double 世界坐标的基础上，把需要高精度运算的部分留在 CPU 双精度层，把最终送给 GPU 渲染的顶点数据转成局部 float 坐标。

为什么不一劳永逸地让 GPU 也用 double？因为 GPU 的顶点处理和像素管线在传统图形 API 里默认就是 float 精度。硬件层面，消费级显卡的 FP64 性能通常只有 FP32 的几十分之一。如果强制用 double 渲染，帧率会崩。UE5 的做法是在 CPU 侧用 double 维护世界坐标，渲染时把物体转换到以相机为原点的局部坐标系，再传给 GPU。这样 GPU 拿到的坐标值很小，float 精度完全够用。

核心 API 与类型变化

在代码层面，LWC 引入了一些新类型和宏，帮助开发者平滑迁移。

最常用的是 FVector 本身。开启 LWC 后，FVector 的 X/Y/Z 成员变成 double。如果你写过的旧代码里有类似 float X = Location.X; 的语句，编译时会得到类型转换警告或错误。UE 提供了 FVector3f 和 FVector3d 两个显式类型，分别对应 float 和 double 版本。需要显式控制精度时，优先用这两个类型。

// UE5.8 在 LWC 开启时
FVector WorldLocation;          // 内部为 double
FVector3f RenderLocation;       // 显式 float，用于 GPU
FVector3d PhysicsLocation;      // 显式 double，用于物理输入

// 转换
FVector3d High = FVector3d(WorldLocation);
FVector3f Low = FVector3f(High);

另外，和世界位置相关的 API 也做了调整。例如 AActor::GetActorLocation() 返回 FVector，也就是 double。蓝图节点默认也返回 double。如果你在蓝图里做坐标运算，不需要额外操作就能享受 LWC 的精度优势。

网络同步方面，旧的 FVector_NetQuantize 类保留了下来，但内部序列化时会对 double 做压缩。UE5.8 引入了 FVector_NetQuantizeDouble 用于需要更高精度的场景。普通的位置同步默认用量化后的单精度或半精度，因为网络带宽有限；只有在关键位置，比如天体轨道、超远程弹道，才需要双精度通道。

USTRUCT()
struct FSpaceCraftState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector_NetQuantizeDouble ExactPosition;

    UPROPERTY()
    FVector_NetQuantize RenderPosition;
};

这个例子展示了典型用法：精确位置用双精度存，渲染位置用压缩后的低精度做插值和预测。客户端看到的位置是平滑后的结果，服务器校验用的位置是双精度的真实值。

网络同步中的坐标

大世界坐标给网络同步带来的挑战不只是数据量变大，还有序列化、预测、一致性和带宽分配。

假设服务器上有一艘飞船位于 $(1.5 \times 10^{10}, 2.3 \times 10^9, -7.8 \times 10^9)$，单位是厘米。这个数值已经超过单精度能精确表示的范围。如果网络包还是用旧格式发三个 float，客户端收到后只能还原到一个粗略位置，误差可能达到几十米甚至上百米。对于太空 demo 来说，这种误差会让 docking、编队飞行、轨道交会完全没法做。

UE5.8 的解决方案是把网络同步分层。服务器内部用 double 计算所有物理和坐标逻辑，向外同步时根据对象重要性选择精度。玩家自己控制的角色、附近的重要物体、需要精确交互的目标，使用双精度或高精度量化；远处背景天体、不重要的碎片，使用低精度或事件驱动同步。

下面这张图描述了服务器到客户端的坐标同步流程。

sequenceDiagram
    participant S as "服务器"
    participant R as "Replication Driver"
    participant C as "客户端"

    S->>S: 用 double 计算世界坐标
    S->>R: 提交同步候选列表
    R->>R: 按距离 / 优先级 / 带宽预算分级
    R->>C: 双精度：玩家飞船、目标天体
    R->>C: 半精度：中距离 NPC / 弹道
    R->>C: 事件：远处爆炸 / 行星掠过
    C->>C: 本地用 double 做预测与插值
    C->>C: 渲染时转相机局部 float

客户端收到位置数据后，不应该直接把 double 坐标填到本地代理上。网络有延迟，直接填会导致跳变。UE 的做法是用本地预测 + 服务器快照做调和。客户端先按自己上次的输入继续推进，等服务器快照到达后计算偏差，再把偏差平滑地吸收掉。这个调和过程需要在 double 精度下进行，否则远处目标的位置会持续漂移。

一个容易被忽略的细节是 RPC 和属性复制的精度一致性。如果你用 FVector_NetQuantize 同步位置，却用 double 在 Server RPC 里传同一个位置，两端拿到的值可能不一致。调试时会出现服务器判定 miss，客户端却显示 hit 的情况。建议一个对象只用一种坐标精度策略，要么全程用 double，要么全程用压缩后的低精度，不要在协议之间混用。

物理与动画的精度

物理模拟对坐标精度非常敏感。Chaos 物理引擎在 UE5 里已经支持大坐标，但它内部并不是直接拿世界坐标做积分。Chaos 的刚体模拟通常在局部坐标系里进行，世界变换只在最后一步合成。

具体流程是：刚体组件从游戏逻辑拿到世界位姿，转成以该物体锚点或最近 sector 原点为基准的局部位姿；Chaos 在局部坐标系里解算速度、角速度、碰撞约束；解算完成后，再把局部结果转回世界位姿。这种局部化设计有两个好处：一是避免大坐标下的精度损失，二是让物理模拟和玩家所在位置解耦，远处物体的物理可以按需降频或休眠。

graph TD
    A["游戏逻辑: 世界坐标 double"] --> B["转局部坐标"]
    B --> C["Chaos 积分 / 碰撞检测"]
    C --> D["速度 / 角速度 更新"]
    D --> E["转回世界坐标"]
    E --> F["渲染: 相机局部 float"]

动画系统也是类似的思路。骨骼动画在局部骨骼空间里运算，不会直接受世界坐标影响。但根运动、IK、布娃娃、布料模拟这些会接触世界坐标的模块需要特别处理。UE5.8 中，动画蓝图里的 World Location 节点返回 double，IK 目标如果用蓝图硬编码坐标，需要注意类型匹配。

小李在修太空 demo 时发现，飞船在远距离航行时，引擎尾焰会偏移。排查后发现是 Niagara 粒子系统把发射器位置写成了 float。Niagara 本身支持 CPU 模拟双精度数据，但 GPU 模拟的粒子属性还是 float。解决方式是把粒子发射位置绑定到场景的相对坐标，而不是世界坐标。对远距离粒子效果，更常见的做法是 LOD：距离远了之后切换成 billboard 或贴图，不再用真实粒子模拟。

原点重置 Origin Rebasing

即使有了双精度世界坐标，实际项目中还是经常用到原点重置。Origin Rebasing 的思路是：把世界原点移动到玩家附近，让所有活跃的物体都落在原点周围的小范围内，这样即使底层是 float，局部坐标也不会触发精度问题。

UE5 提供了一个专门的子系统 ULargeWorldCoordinatesOriginManager 来管理原点重置。在纯 LWC 模式下，你可以不使用原点重置，直接用 double 撑到极大的世界范围。但在很多情况下，LWC 和 Origin Rebasing 会组合使用：LWC 负责服务器端的世界坐标和跨远距离一致性，Origin Rebasing 负责把活跃区域的局部坐标控制在合理范围，进一步降低渲染和物理子系统的压力。

原点重置的常见触发条件是玩家离开当前原点一定距离。比如当前原点在 $(0,0,0)$，玩家飞到 $(500000, 0, 0)$ 时，把原点重新设为 $(500000, 0, 0)$。所有活跃物体的世界坐标都会被减去这个偏移量，相对位置保持连续。对玩家而言，场景没有变化；对底层系统而言，所有局部坐标都回到了原点附近。

下面这张图展示了原点重置前后的坐标关系。

graph LR
    subgraph 重置前
        O1["原点 0,0,0"]
        P1["玩家 500000,0,0"]
        A1["天体 1000000,0,0"]
    end

    subgraph 重置后
        O2["原点 500000,0,0"]
        P2["玩家 0,0,0"]
        A2["天体 500000,0,0"]
    end

    O1 --> |"偏移量"| O2
    P1 --> P2
    A1 --> A2

原点重置有几个需要注意的坑。

第一，静态网格和关卡流送。如果原点改变，已经加载的子关卡内部坐标会变化，需要确保流送系统知道新的原点。UE5 的 World Partition 已经内建了相关支持，旧的手动关卡流送方案可能需要自己处理偏移。

第二，网络同步。服务器和客户端的原点可能不一致。每个客户端以自己的观察位置为原点，服务器以全局坐标为原点。网络同步协议需要携带当前的原点偏移，客户端收到后把自己的本地坐标转换成服务器全局坐标，再做预测和校验。

第三，持久化数据。存档、任务标记、地图标记点需要存全局坐标，不能存重置后的相对坐标。否则下次读档时原点可能不同，标记位置会错。

性能影响

LWC 带来精度提升的同时，也带来了额外的性能开销。双精度浮点数的内存占用是单精度的两倍。一个 FVector 从 12 字节变成 24 字节。如果场景里有大量物体，内存占用会明显增加。变换矩阵 FMatrix 从 64 字节变成 128 字节，骨骼数量多的角色会多吃不少显存和内存。

CPU 计算方面，现代 x86_64 处理器对 double 运算的支持很好，标量 double 加减乘除和 float 的延迟接近。SIMD 场景下差距会大一些，因为 256 位 AVX 寄存器一次只能装 4 个 double，但能装 8 个 float。如果代码里大量依赖 SIMD 批量处理坐标，改 double 后吞吐量可能下降一半。UE5 在核心数学库里做了不少优化，比如保留 FVector3f 用于渲染路径，减少不必要的 double SIMD 运算。

GPU 方面，前面已经说过，渲染管线还是以 float 为主。UE5 会在 CPU 侧把最终渲染矩阵转成 float，再提交到 GPU。这个转换本身有一点开销，但通常可以忽略不计。真正需要注意的是 Compute Shader 和 Niagara GPU 模拟，如果它们读取或写入世界坐标，需要确认精度是否够用。

网络带宽方面，双精度坐标同步会占用更多字节。一个 FVector3d 裸传是 24 字节，而 FVector_NetQuantize 通常只有 6 到 12 字节。大多数对象不需要双精度同步，UE5.8 的分级策略可以把带宽开销控制得很好。只有关键对象开启高精度通道，其它对象继续用压缩格式。

电池和移动平台是另一个需要考虑的因素。ARM 处理器的 FP64 性能差异很大。高端芯片和 Apple Silicon 的 double 运算很快，中低端 Android SoC 的 FP64 吞吐量可能只有 FP32 的几分之一。如果目标平台包含移动设备，需要在 LWC 精度和能耗之间做权衡。

平台差异

LWC 不是全平台无差别生效的。不同硬件架构、图形 API、编译目标对 double 的支持程度不同。

在 Windows x86_64 上，LWC 完全受支持。Visual Studio 和 Clang 都能正确编译 double 版本的 FVector。DX12 和 Vulkan 后端会把最终渲染数据转成 float，过程透明。

在主机平台，PlayStation 5 和 Xbox Series X|S 的 CPU 和 GPU 都支持 double。虽然 GPU 渲染仍然走 float，但 Compute Shader 可以根据需要开启 FP64。这两台主机的内存带宽比较充足，LWC 带来的内存增加通常可以接受。

Linux 服务器端是 LWC 收益最明显的场景。Dedicated Server 需要处理大量玩家的世界坐标和物理模拟，double 能显著减少远距离物体的抖动和判定错误。UE5.8 的 Linux 服务器构建默认开启 LWC。

移动平台要分情况。iOS 的 A 系列和 M 系列芯片对 FP64 支持较好，但 Metal API 里 GPU 端还是 float 为主。Android 碎片化严重，部分低端 GPU 的 FP64 性能非常弱。如果项目要上移动平台，建议只在服务器或高端设备上启用完整 LWC，中低端设备可以通过 Origin Rebasing 配合单精度渲染来兼容。

WebGL 是一个特殊的存在。当前主流浏览器的 WebGL 2.0 实现不支持 double 类型的顶点属性，JavaScript 里的 Number 虽然是 64 位浮点，但 GPU 交互层只能用 float。如果做 Web 端预览或流送，需要在服务器或中间层把 double 坐标裁剪到相机局部 float 再下发。

回到那个太空 demo

小李最后怎么解决抖动问题的？他没有改动一行渲染代码，而是分三步走。

第一步，确认项目启用了 LWC。在 .uproject 文件里，bLargeWorldCoordinates 设为 true。UE5.8 新建项目默认开启，但老项目升级时需要手动检查。

{
  "EngineAssociation": "5.8",
  "Category": "",
  "Description": "",
  "Modules": [],
  "Plugins": [],
  "bLargeWorldCoordinates": true
}

第二步，把所有涉及世界坐标的自定义结构体从 float 改成 double 或 FVector。他之前自己写了一个轨道计算组件，内部用 float 存星历数据，远距离时误差被放大。改成 double 后，轨道预测稳定了很多。

第三步，给粒子、音效、相机震动的位置输入都改成相对坐标。远距离物体的表现不再依赖世界坐标的绝对精度，而是依赖相对于飞船的局部精度。视觉上的抖动基本消失。

做完这三步，飞船飞到 $10^{10}$ 厘米外时，画面依然稳定。美术大哥再次路过，盯着屏幕看了一会儿，说：这回像真的太空了。

排查清单

如果你也在做大世界项目，遇到坐标相关异常，可以按这个顺序排查。

世界坐标抖动或物体抽搐：先确认项目是否启用了 LWC，再检查相关结构体是否混用了 float 和 double，最后看渲染路径是否把大坐标直接传给了 GPU。

远距离网络同步位置漂移：检查网络序列化用的类型，确认关键对象是否使用了 FVector_NetQuantizeDouble 或自定义双精度通道。同时确认客户端预测和服务器快照在同一坐标空间下运算。

物理碰撞穿模或刚体异常：查看 Chaos 是否在局部坐标系下运行，世界到局部的转换矩阵精度是否足够。远距离物体可以启用物理休眠或降频。

粒子、贴花、音效位置偏移：把这类表现系统绑定到相对坐标或 Attach 到场景组件，不要直接喂世界坐标。

存档或地图标记读档后位置错误：确认持久化数据存的是全局 double 坐标，而不是 Origin Rebasing 后的相对坐标。

移动端性能下降：检查目标设备的 FP64 能力，必要时在低端设备上关闭部分 LWC 特性，改用 Origin Rebasing 方案。

大世界坐标不是开关按下去就万事大吉的特效，而是一套需要全链路配合的机制。UE5.8 已经在核心层把路铺好，剩下的工作是把服务器、网络、物理、动画、渲染和音效各条路径都检查一遍，确保它们知道自己拿到的坐标是 double，并且知道什么时候该转成 float。把这些边界理清楚，才能真正做出让玩家飞遍整个星系也不抖动的世界。