#133 Mac（原生Metal）：世界渲染出现颜色通道损坏，并随游玩时间加重

状态: 待审核 · 分类: 画面与美术 · 渲染与性能

Mac原生客户端中世界画面出现洋红、黄等偏色，界面正常，且越玩越严重。

当前表现

在原生 Mac 客户端上，世界渲染会丢失一个或多个 RGB 通道。受影响的表面会呈现强烈的偏色——洋红、黄、青、绿——或者一个通道被削弱而其他通道保持正常。该问题在全新加载时就存在，并且会随着游玩时间变得更严重。 **界面不受影响。** 在同一帧中，动作条、姓名板和聊天框的颜色是正确的，而世界的颜色则不正确。在一次截图中，世界渲染中任何位置的蓝色最大值都只有 34，而同一帧中界面元素达到了 240–254。这种差异是该问题最明显的特征，也是最容易检查的地方。 **实测，暮色森林，版本 1.60.1.70009**（macOS 数码测色计，显示器原生数值）： | | R | G | B | R/G | |--------------|-----:|-----:|-----:|-----:| | 树皮 | 4.9 | 36.9 | 52.0 | 0.13 | | 草地 | 10.0 | 39.5 | 46.8 | 0.25 | | 树冠 | 5.7 | 33.2 | 46.1 | 0.17 | | 枯树 | 2.2 | 33.3 | 47.4 | 0.07 | 树皮的红色只有绿色的七分之一，这可不是什么“氛围阴郁的地区”。 **一个通道会彻底消失，而不只是变暗。** 矮人区的一面石墙采样结果为 R 0、G 58、B 0——红色和蓝色完全消失，绿色不受影响。在同一场景中相邻的一个绿色表面上，测色计读数为 R 0、G 66、B 0。 **两种不同的故障模式同时存在。** 在 483 个测色计采样中，84% 的采样里红色恰好为 0，中位数为 0，且其数值与表面亮度的相关性为 0.04——也就是说，无论光照如何它都是关闭的。蓝色在 15% 的采样中恰好为 0，中位数为 6，与亮度的相关性为 0.48。一个通道被清零；另一个通道则在连续范围内被衰减，没有量化断层。 **在没有任何其他变化的情况下，它会随游玩时间加重。** 同一地点、同一镜头，相隔约三分钟： **它会按面积扩散，而不仅仅是变得更深。** 受影响区域内的通道比值大致保持不变，而区域本身在不断扩大。以下三张图是从同一视角在几秒内拍摄的，可以看到一片绿色区域在吞噬一个琥珀色的场景： 我提到这一点，是因为我花了好几天在固定区域测量通道比值，而这种方法从设计上就无法发现面积扩散。如果你在检查某项改动是否有帮助，请测量受影响的面积，而不仅仅是偏色的深度。 **受影响区域有硬边缘，边缘跟随世界几何，而不是屏幕。** 在镜头移动过程中追踪可见边界，相对纹理空间模型的误差为 2.7 像素，而相对屏幕空间模型的误差为 12.7 像素。 **它不局限于某一个区域或某一种色调。** 同样的故障，四个区域，四种不同的偏色： **严重到会被误认为几何体渲染成黑色，这一点很重要。** 同一个艾尔文森林山坡在相隔几分钟的两帧： 较早 较晚 整帧 R 75.2 42.2 G 59.0 49.9 B 17.7 11.7 R/G 1.28 0.85 树丛，最暗的 10% 平均亮度 24.4 3.9 R / G / B 35/31/8 3/4/4 画面中亮度低于 20 的比例 1.2% 20.3% 每一组都是在几秒内快速发展，使每个受影响的图块逐渐变得接近黑色。 该帧中恰好为零的像素占 0.149%。我特别指出这一点，是因为它看起来与此版本中已修复的另一个黑色几何体故障完全一样，而唯一可靠的区分方法是“恰好为零”还是“只是偏暗”。在得出结论之前请先测量。 **它不是什么。** 通过测试已排除：一天中的时间、画面内容、镜头位置、高度、区域、室内与室外、副本与野外、阵营、角色年龄、纹理分辨率、投射纹理，以及所有其他图形设置。清除 `Cache/` 和 `WTF/` 也不会影响它。它出现在从未去过的区域的全新角色身上，也出现在世界加载之前的新角色开场动画中——在该动画中，红色每帧有 232–255 个不同的层级，而绿色大约只有一半，蓝色更少。紧接着该动画之前的 2D 加载画面测量结果完全正常：158,953 个亮起的像素，没有任何通道恰好为零。 **在同一台机器上通过 D3D12 转译到 Metal 时不会复现。** 在同一台 Mac 上通过 CrossOver 运行 Windows 客户端（Rosetta x86_64 → D3D12 → Game Porting Toolkit 3.0 → Metal）——相同的 GPU、相同的 Apple 驱动、相同的 Metal 框架、相同的版本、相同的设置、相同的角色、相同的坐标，相隔几分钟： | | 原生 Metal | D3D12 → Metal | |--------------------|-----------------------|----------------------------| | 悬崖表面 | R 66.5 G 5.5 B 27.4 | R 98.8 G 94.6 B 104.7 | | 第二块悬崖区域 | R 44.6 G 2.8 B 15.3 | R 126.8 G 100.4 B 95.1 | | 蓝色石板屋顶 | R 26.3 G 40.5 B 73.3 | R 68.8 G 73.8 B 82.1 | 原生渲染下悬崖表面的绿色读数为 5.5 和 2.8。而转译下相同的表面读数为 94.6 和 100.4，并且每个通道都存在全部 256 个层级。 **需要说明我为什么做这个测试：它是一种诊断手段，而不是推荐方案。** 我并不建议任何人使用 CrossOver 来游玩，我也不希望这变成本周的 Mac 临时解决方案。保持硬件不变而只更换图形后端，是我能用来说明故障“不在哪里”的最干净的办法。 它排除了硬件、Apple 的 Metal 驱动、GPU 以及光照计算——因为两个后端使用的是同一套源码中的相同算法。区别在于，原生路径编译的是暴雪自己的 Metal 着色器并构建其 Metal 渲染通道，而转译路径运行的是由第三方转换层转成 Metal 的同一份 DXIL。 **系统：** Mac Studio (2025)，M4 Max，128 GB，macOS 26.7 (25G229)，2 台外接显示器。 **版本：** 1.60.1.70009。在 1.60.1.69977 上同样存在。 --------------------------------------------------------------------------------

预期表现

世界几何体的渲染应保留全部三个颜色通道，其保真度应与同一帧中界面渲染路径已达到的水平相同。 具体来说： - 中性灰色表面应满足 R ≈ G ≈ B。目前测得的比值低至 0.24。 - 在大面积受光、带纹理的几何体上，不应有任何通道恰好为 0。 - 在位置、一天中的时间或设置没有变化的情况下，渲染颜色不应在一个游戏会话中发生变化。 - 对于同一场景，原生 Metal 后端应产生与 D3D12 转译路径在同一硬件上相同的通道数值。 下图是在这台机器上、同一客户端、同一会话中正确的效果：

复现步骤

1. 在 Apple Silicon 上启动 Mac 客户端（原生，图形 API：Metal）。
2. 创建新角色，或登录现有角色。不需要特定区域——在我测试过的所有地方都能复现，包括室内和副本内。
3. 如果创建了新角色，观看开场动画。在世界加载之前，损坏就已经存在了。
4. 进入世界，前往一个正确颜色毫无争议的表面——暴风城贸易区的灰色石头是个不错的选择，因为它的 R、G、B 读数应该相近。
5. 使用 **macOS** 截图（Cmd+Shift+4），而不是游戏内截图键，这样截图路径就不会重新压缩任何内容。
6. 用数码测色计（macOS 内置，设置为“显示原生数值”）对该表面采样，并与同一帧中的某个界面元素进行比较。
7. 在不更换区域或设置的情况下正常游玩 20–30 分钟，然后在同一地点、同一镜头角度重复步骤 4–6。比值会进一步偏移。

**两个值得了解的陷阱，因为我两个都中过：**

- **区域自身的色调可能掩盖或模仿这一故障。** 提瑞斯法的灰绿色让我一个小时都没发现绿色偏色；杜隆塔尔的橙色让红色占主导的损坏看起来像正常光照。不要根据地形判断。请在你已知颜色的表面上判断，并且最好使用成对对照——同一地点、同一镜头，只改变一个变量。
- **不要固定一个表面然后等待。** 光照会随一天中的时间变化，所以任何“固定表面随时间观察”的方案都会产生误报。请使用光照固定的区域，或与同一帧中的界面元素比较。