Skybox 格式详解：Equirectangular、Cubemap 与 HDRI 对比（2026）

一句话总结

如果你的目标平台是 Unity URP/HDRP、Unreal 5 或现代 WebGL，用 equirectangular（2:1 PNG/EXR）。如果目标是 Unity 旧版内置管线、不支持高精度全景采样的移动端 GPU，或者需要 cube 反射的 Three.js 场景，则转换成 cubemap（6 个面）。只有当你真正需要 IBL 照明贡献（而不仅仅是背景）时，才选 HDRI（.hdr/.exr）。三种格式描述的是同一个场景——区别只在于像素是如何解包的。

一条实用经验法则：如果你的引擎内置了"Panoramic"或"HDRI Backdrop"天空盒 Shader，且运行在现代 GPU 上，就保持 equirectangular 格式，直接跳过转换步骤。你不会损失任何质量，还能让管线保持简洁。Cubemap 是在引擎或硬件逼你的时候才选的答案，而不是因为你在照着 Unity 5 时代的旧教程操作。

生成全景图 →

转换成 cubemap →

三种格式速览

三种格式底层表示的是同一份数据：一个 360°×180° 的环境视图。区别纯粹在于球形数据如何被展开成文件，以及 GPU 或渲染器在运行时如何还原它。从同一个源生成的 equirectangular 全景图和 cubemap 在数学上是等价的——同样的光子，不同的几何布局。HDRI 增加了第三个维度：线性、高动态范围像素，而非 gamma 编码的 8-bit 值。理解这三个维度（布局、几何、位深）就是这道题的全部。

Equirectangular（2:1 全景图）

Equirectangular 是在单个文件中存储完整 360° 环境的标准格式。名称来源于同名地图投影：经度映射到水平轴，纬度映射到垂直轴，结果是一个 2:1 宽高比的矩形。一张 4096×2048 的图像覆盖 360° 宽、180° 高——完美对应它所代表的球面。

这种投影会引入可预测的畸变。靠近赤道（图像垂直中心）的像素密集排列，比例均匀。靠近极点（上下边缘）的像素则大幅拉伸——图像顶部附近一个水平像素带在球面上可能只代表 1° 的垂直弧度，却与靠近赤道、跨越 10° 的像素带占用相同数量的像素。这就是为什么 equirectangular 格式生成的天空在平铺查看时顶部和底部看起来模糊，但映射到球面或天空盒 Shader 内部时却完全正确。

对于现代引擎来说，极点畸变不是问题。天空盒 Shader 在内部处理 UV 重映射。Unity 的 Panoramic skybox Shader、Unreal 的 HDRI Backdrop actor、Babylon.js，以及 Three.js 的 EquirectangularReflectionMapping 都直接接受 2:1 equirectangular 格式，并在 GPU 上完成球面映射。你只需给引擎一张图，其余的它全包了。

优点： 单文件。任意图像查看器都能预览。被现代工具广泛支持。需要修补接缝时可直接在 Photoshop 或 GIMP 中编辑。这也是 AI 全景图生成器、360° 相机和绝大多数环境绘制工具的标准输出格式。

缺点： 极点畸变让手绘变得困难。不是旧版或移动端 GPU 的原生格式。某些旧版反射探针工作流程需要 cubemap。分辨率很高的 equirectangular（比如 8192×4096）会把大量像素预算浪费在过采样的极点区域上。

在 2026 年的大多数工作流程中，equirectangular 是正确的起点。只有在目标系统确实需要 cubemap 输入时才进行转换。

更深入了解这种格式本身，请参阅什么是 equirectangular 图像？。

Cubemap（6 个面）

Cubemap 将环境表示为六个正方形面：正 X、负 X、正 Y、负 Y、正 Z、负 Z——也就是右、左、上、下、前、后。每个面都是一个标准透视渲染，90° 视场角。将六个面拼合在一起，你就得到了一个完整的球体——没有极点畸变，整个表面像素密度均匀。

命名约定

六个面在不同引擎或工具中有不同的命名约定。以下是最常见的四种：

命名搞错是导致天空盒上下颠倒或里外翻转的最常见原因。拿不准的时候，先逐个加载每个面并验证方向，再批量处理。cubemap 生成器允许你在导出时选择命名约定，这样就能直接匹配引擎的预期，无需手动重命名。

Cubemap 的适用场景

Unity 旧版内置管线： Unity 的内置管线比全景采样 Shader 的广泛支持还要早。默认的 6-Sided 天空盒 Material 需要六张独立贴图，每个面一张。如果你在内置管线上发布移动端游戏，或者在维护一个早于 URP 的旧项目，那么在不重写天空盒系统的前提下，cubemap 是你唯一的实际选择。

Unreal Cube Render Target： UE5 的反射捕捉 actor 和 Cube Render Target 原生基于 cubemap。如果你在将反射烘焙到静态关卡，或者构建反射探针工作流，即使你导入的是 equirectangular 资产，在引擎层面你操作的也是 cubemap。

Three.js CubeTextureLoader： Three.js 的 CubeTextureLoader 需要六个文件。如果你在构建一个使用 THREE.CubeReflectionMapping 做环境映射 Material 的 WebGL 场景，你就需要独立的面文件。THREE.EquirectangularReflectionMapping 是现代设置的替代方案，但 CubeTextureLoader 在许多入门模板中仍是默认选项。

移动端 GPU 性能： 在低端 Android 设备上，从单张 2:1 贴图做全景采样可能比从 cubemap 采样更耗性能，因为 GPU 需要在每个片元上计算 UV 投影。预烘焙的 cubemap 把这部分计算移到了加载时。在现代中端手机上实际差异很小，但对于大规模部署的低端硬件来说还是有影响。

优点： 像素密度均匀，极点不浪费分辨率。反射探针的原生格式。旧版管线的必备选项。面布局清晰，方便美术手绘。

缺点： 需要管理六个文件。各引擎命名约定不统一。手绘时需要仔细处理面与面之间的接缝。如果源文件是 equirectangular，需要额外的转换步骤。

你可以通过我们的 cubemap 生成器在浏览器中将任意 2:1 equirectangular 转换为 cubemap——纯前端运行，无需上传，免费。

HDRI（高动态范围图像）

HDRI 是 High Dynamic Range Image 的缩写。"高动态范围"才是关键词。标准 8-bit PNG 每个通道存储 256 个离散值，典型动态范围约 2–3 档曝光。32-bit float HDRI 则存储从接近零到数万的浮点值——动态范围超过 20 档。用更直观的方式说：真实户外 HDRI 中的太阳比汽车底部阴影亮 100,000 倍，文件完整地保留了这个比值。

正是这个比值使 HDRI 在**基于图像的照明（IBL）**中不可替代。当渲染器从 HDRI 环境贴图中采样漫射和镜面反射贡献时，它用文件中的实际亮度值来计算逼真的光线弹射和高光。一个真实 HDRI 中明亮的太阳，会在抛光表面上产生锐利的镜面高光。同样的场景如果存为 8-bit LDR，高光就会变得过曝且平淡——渲染器会把整个天空当作几乎相同的亮度，因为文件本身无法表示其中的差异。

文件格式

两种主流 HDRI 容器格式：

• Radiance .hdr（也叫 RGBE）：一种由 Greg Ward 在 1980 年代开发的旧格式。将 32-bit 值编码为每像素 8-bit 尾数 + 8-bit 共享指数（RGBE 编码）。Blender、Substance Painter、Marmoset 和大多数 DCC 工具都广泛支持。文件体积比 EXR 小。AI HDRI 生成器输出的就是这种格式。
• OpenEXR .exr：现代视效和高端渲染的行业标准。每通道真正的 16-bit 或 32-bit 浮点，没有共享指数的妥协。支持多层、多 part 和平铺格式。在 VFX 管线中首选，Blender Cycles 和 Unreal Engine 的 HDRI Backdrop（.exr 输入）均支持。

HDRI 与背景——一个诚实的区分

很多游戏开发内容把"HDRI 天空盒"和"HDRI 照明"混为一谈。它们并不是同一回事。如果你只想要一个视觉上好看的天空作为关卡背景，并不依赖环境贴图提供照明贡献，你根本不需要真正的 HDRI。一张 8-bit LDR equirectangular 全景图效果完全相同，文件大小却小得多。天空是背景；它不需要 32-bit 精度。

以下情况才真正需要 HDRI：

• 你的 PBR 材质需要来自主光源（太阳、面光、霓虹灯）的精确镜面高光。
• 你想要来自环境的柔和、有方向性的环境光，而不想手动布置灯光。
• 你在做 look-dev 或产品可视化，曝光精度很重要。
• 你在为虚拟制作匹配真实拍摄的环境。

关于 AI 生成 HDRI 的诚实说明

AI 全景图生成器——包括我们自己的 AI HDRI 生成器——生成的是 8-bit LDR 像素。输出结果被封装在 Radiance .hdr 容器中，从技术上讲这确实是一个"HDRI 文件"。但像素数据仍然是 8-bit、经过色调映射和 gamma 编码的。AI 生成的天空中的太阳并不比阴影亮 100,000 倍——最多高出 3–4 档曝光，和任何 8-bit 图像一样。

实际意义：AI HDRI 非常适合柔和的环境 IBL、氛围方向、虚构室内场景和背景多样化。它能给你来自亮天区域的可信镜面反射。但它无法给你来自 Poly Haven 包围曝光摄影 HDRI 的那种锐利、物理精确的太阳高光。两者各有用处，开工前先搞清楚你需要哪种。

追求真实 HDR 的话，使用 Poly Haven（CC0，实拍，质量出色）或 Lumiere 获取影棚级 HDRI。需要速度、数量和虚构场景时，选 AI 生成。

格式转换路径

理解格式之间的转换路径，可以避免不必要的往返转换和有损操作。

Equirectangular → Cubemap 是最常见的方向。可选方案：

• Cubemap 生成器（浏览器端，免费，无需上传，支持四种引擎命名约定）
• Blender Compositor：使用 Equirectangular 节点接入六个带 Cube 投影相机设置的渲染
• panorama-to-cubemap npm 包：在 Node.js 中运行并输出各面 PNG 的 JavaScript 库

Cubemap → Equirectangular 较少见，但有时有需要（比如你手头只有 cubemap 资产，需要在全景编辑器中修改环境）。可选方案：Photoshop（使用透视变形工具手动拼合，繁琐但可行）、Blender（相机装置渲染）、带自定义变换矩阵的 ImageMagick。目前我们的浏览器工具不支持这个方向——如果需求量增大会加入路线图，但在没有 WebGL compute 的浏览器环境下，这个方向的数学要复杂得多。

8-bit LDR PNG → HDR 容器： 我们的 AI HDRI 生成器将 LDR 全景图封装在 Radiance .hdr 文件中，让 Blender、Unreal 和 Unity HDRP 无需你做额外转换即可直接导入。像素值仍然是 8-bit LDR。真正的 HDR 捕获——实现真实的 20+ 档动态范围——需要包围曝光摄影（5–7 张曝光，在 Lightroom 或 PTGui 中合并），或在带有真实相机模型的物理渲染器中渲染。没有任何算法能从单张 8-bit 源图中恢复真正的 HDR。

该选哪种格式？

你在用 URP / HDRP / UE5 / WebGL / 现代引擎吗？
├─ 是 → 使用 equirectangular，引擎原生支持。
└─ 否 → 你在用 Unity 旧版管线或移动端吗？
    ├─ 是 → 转换为 cubemap。
    └─ 否 → 你在做 IBL 照明（不只是背景）吗？
        ├─ 是 → 使用 HDRI（32 位真 HDR，如 Poly Haven）。
        └─ 否 → 用 equirectangular 即可。

各引擎快速参考：

• Unity URP： Panoramic skybox Material。使用 equirectangular（PNG 或 EXR）。单文件，无需转换。
• Unity HDRP： HDRI Sky volume 组件。照明用 equirectangular EXR 或 HDR；纯背景用 equirectangular PNG。
• Unity 内置管线： 6-Sided skybox Material。使用 cubemap（6 个面）。用我们的 cubemap 生成器转换。
• Unreal Engine 5： HDRI Backdrop actor。使用 equirectangular HDR/EXR。对于 Lumen，Unreal 会使用环境贴图提供间接照明贡献——这里用真实 HDRI 效果最好。
• Blender Cycles： World Shader 配合 Equirectangular Environment Texture 节点。使用 equirectangular HDR/EXR。位深直接影响反射材质上镜面高光的质量。
• Blender Eevee： 节点设置与 Cycles 相同。Eevee 内部使用反射 cubemap，但输入仍然是 equirectangular——Eevee 在场景加载时会自行从中烘焙 cubemap。你不需要手动提供 cubemap。
• Three.js： 现代设置用 EquirectangularReflectionMapping（单张 equirectangular PNG/HDR），旧版设置用 CubeTextureLoader（6 个面文件）。如果是新项目，用 equirectangular——这能显著简化资产管线。
• WebXR / A-Frame： a-sky 组件接受 equirectangular。360° 图像查看器和完整 VR 场景使用的是同一种格式。除非你在实现自定义反射 Shader，否则不需要 cubemap。

常见陷阱

1. 拼接线处出现可见接缝。 Equirectangular 全景图在左右边缘处环绕。如果左边缘像素行与右边缘像素行不匹配，你的天空盒中就会出现一条可见的垂直条纹。这种情况最常发生在 AI 生成时，模型在图像边缘引入了随机噪声或暗角。Skybox Generator 内置了专门调优的 prompt 重写器和生成管线，以最大程度减少接缝伪影——模型经过条件训练，会生成无缝环绕的天空。如果你用通用图像模型生成，则需要在 Photoshop 中进行水平接缝混合处理（将图像水平偏移 50%，混合新的中心，再偏移回来）。

2. Cubemap 面方向错误。 不同引擎对坐标系和手性的期望各不相同。Unity 使用左手 Y-up 坐标系；Unreal 使用左手 Z-up 坐标系。同一个 cubemap 资产在不同引擎中可能产生镜像或旋转的结果。最安全的工作流程是使用引擎专属命名约定，并在组装最终天空盒之前，将每个面作为普通贴图加载来验证方向。我们的 cubemap 生成器会在输出文件上明确标注你选择的约定，因此 Unity、Unreal、Three.js 和 Blender 的导出各自会得到正确的面方向。

3. 将 8-bit 内容当作 HDR 使用。 将 8-bit PNG equirectangular 作为 World Environment Texture 加载进 Blender Cycles 技术上可行——Blender 会接受——但你无法从太阳处获得物理可信的镜面反射。文件根本没有足够的动态范围。Blender 会把每个像素都压缩进同样狭窄的区间，你的高光将柔和而毫无细节。如果场景对 IBL 质量有要求，你需要真实的 HDR 源数据。这同样适用于 AI 生成的 .hdr 文件：容器格式是 HDR，但内容可能是 LDR。在确定使用某个 HDRI 源之前，先在你的 DCC 工具中检查直方图。

4. 源图分辨率与 cubemap 面尺寸不匹配。 如果从 2048×1024 的 equirectangular 中提取 1024×1024 的 cubemap 面，你每个面实际上只从约 512×512 像素的有效源数据中采样（其余部分分配给相邻面）。结果会显得粗糙，在透视畸变最大的面角落处尤为明显。经验法则：源 equirectangular 的宽度至少要是目标 cubemap 面尺寸的 4 倍，才能得到干净的结果。对于 1024×1024 的面，从 4096×2048 的 equirectangular 开始。对于 2048×2048 的面（大多数游戏用例的质量上限），使用 8192×4096 的源图。

生成你的第一张 skybox

如果你是从零开始，最快的路径是用自然语言描述你的环境，直接生成 equirectangular 全景图。Skybox Generator 一步完成 prompt 优化、接缝环绕和 2:1 输出。生成的图像无需任何转换，可直接导入 Unity URP、HDRP、Unreal 5 或任意 WebGL 场景。

如果你的目标是需要六个 cubemap 面的旧版管线或移动端引擎，将输出结果传入 Cubemap Generator。选择引擎的命名约定（Unity、Unreal、Three.js 或 Blender），下载 zip 包并导入。整个管线——从生成到 cubemap——完全在浏览器中运行，无需服务器上传。

专门做 IBL 照明的话，查看 AI HDRI 生成器的 Radiance .hdr 导出。记住上面提到的 LDR 说明：用它做柔和环境光和氛围渲染，硬高光精度则用 Poly Haven 的资产来补充。

相关阅读

• 什么是 equirectangular 图像？
• Blender/UE/Unity 的 AI HDRI
• 如何写 360° 全景图 prompt