Unity与UE4法线贴图转换：解决引擎间渲染差异的Python脚本

1. 项目概述：当法线贴图遇上引擎“方言”

如果你同时用Unity和Unreal Engine 4（UE4）做过项目，或者从某个资源商店买了一套带法线贴图的模型资产，准备在两个引擎里复用，那你很可能踩过这个坑：同一张法线贴图，在Unity里看起来凹凸有致、细节完美，但一导入UE4，模型表面那些精心雕刻的划痕、凹槽和凸起，全都“反”了。本该凹陷的地方变成了凸起，本该是受光面的地方却变成了阴影面，整个模型的立体感和质感完全错乱。这不是你的美术资源出了问题，也不是引擎有Bug，而是两大主流游戏引擎在图形渲染的“底层方言”上，一个根本性的差异所导致的。

这种现象，被戏称为游戏引擎的“内卷”现场。这里的“内卷”并非指行业竞争，而是指在追求极致渲染效果和性能的过程中，不同引擎基于各自的历史沿革、技术选型和合作生态，形成了不同的技术标准和实现路径。对于法线贴图这种核心的细节增强技术，Unity和UE4就采用了不同的坐标系约定，导致同一张图在两个引擎里产生了镜像般相反的效果。理解这个差异，不仅是解决眼前资产兼容问题的钥匙，更是深入理解现代实时渲染管线、贴图空间和着色器工作原理的一个绝佳切入点。

本文将彻底拆解Unity与UE4在法线贴图处理上的核心差异，从图形API的底层标准、引擎的默认配置，到生产管线中的实际影响。更重要的是，我会提供一个经过实战检验的、高效的一键转换Python脚本，并详细解释其背后的像素操作逻辑，让你不仅能快速解决问题，更能知其所以然，在未来规避类似问题，提升跨引擎工作流的效率。

2. 核心原理拆解：法线贴图与坐标空间的“战争”

要理解为什么同一张图会“长相反”，我们必须先搞明白法线贴图到底是什么，以及它在渲染中扮演的角色。

2.1 法线贴图的核心作用与存储原理

法线贴图（Normal Map）是一种特殊的纹理，它不存储颜色信息，而是存储每个像素点对应的表面法线方向。在3D渲染中，法线决定了光线如何从表面反射，是计算光照（特别是高光）的关键输入。一个模型的实际几何形状由顶点和三角形（即“高模”）定义，但为了表现丰富的表面细节（如皮肤皱纹、砖墙缝隙、金属划痕），如果全部用高精度几何体来实现，性能开销将无法承受。

法线贴图的妙处在于，它能在低多边形模型（即“低模”）的表面上，通过改变每个像素点的法线方向，模拟出高模才有的复杂光照反应，从而“欺骗”我们的眼睛，看到仿佛存在几何细节的凹凸效果。这是一种以极小的性能代价（主要是一张额外的纹理采样和几次向量计算）换取视觉质量巨大提升的技术。

那么，一个三维的法线方向（一个长度为1的向量）是如何被“压扁”存储到一张二维的RGB图片里的呢？答案是向量分量映射。一个标准化的法线向量 (X, Y, Z) 分量取值范围是 [-1, 1]。而一张图片的RGB通道每个分量的取值范围是 [0, 255]（8位）或 [0, 1]（归一化后）。因此，需要一个映射公式：存储值 = (法线分量 * 0.5) + 0.5这样，当法线分量为 -1（完全指向负方向）时，存储值为0；为0时，存储值为0.5；为1时，存储值为1.0。读取时再反向操作即可还原出法线向量。

2.2 差异根源：OpenGL与DirectX的“左右手”坐标系之争

Unity和UE4法线贴图表象差异的根源，在于它们所遵循或默认适配的图形API标准不同，这直接导致了切线空间（Tangent Space）的Z分量（有时是Y分量）指向相反。

• Unity的“血统”：OpenGL传统。Unity诞生之初，为了支持跨平台（尤其是早期的Mac、Linux和移动端），其渲染管线深度继承了OpenGL的规范。在OpenGL的约定中，切线空间的Z轴（即法线贴图中的蓝色通道B）指向模型表面的外侧（即从表面指向外部空间）。你可以想象你的手掌是模型表面，掌心朝外时，从掌心垂直向外伸出的手指方向就是Z轴正方向。因此，在Unity中，一张未经压缩的、正确的法线贴图，其蓝色通道（B）在平坦区域应该是最亮的（接近白色），因为Z分量接近1.0，存储值也就接近1.0（白色）。

• UE4的“基因”：DirectX传统。Unreal Engine自诞生起就与Windows平台和DirectX API紧密绑定。在DirectX的约定中，切线空间的Z轴（蓝色通道B）指向模型表面的内侧（即从表面指向模型内部）。沿用手掌的比喻，现在掌心朝内贴着自己，从掌心垂直向内（朝向自己身体）伸出的方向才是Z轴正方向。因此，在UE4中，一张正确的法线贴图，其蓝色通道在平坦区域应该较暗，因为Z分量是-1.0或接近-1.0，经过映射公式(-1 * 0.5) + 0.5 = 0.0转换后，存储值就是0（黑色）。

这就导致了根本性的对立：对于同一个“向外”的表面法线，在Unity的规则里，其切线空间Z分量为+1；在UE4的规则里，其切线空间Z分量为-1。当引擎从法线贴图的蓝色通道读取存储值并试图还原Z分量时，就会得到符号相反的结果。这个相反的Z分量，与X、Y分量一起组成法线向量参与光照计算，最终导致光照判断完全颠倒，凹凸效果也就反了。

注意：这里为了概念清晰，我们简化了描述。实际上，这个差异更常见的表述是关于Y轴（绿色通道G）的翻转。这是因为在将高模烘焙到低模生成法线贴图时，不同的烘焙软件（如xNormal, Substance Painter, Marmoset Toolbag）和不同的引擎，对于纹理空间V坐标（垂直方向）是向上还是向下的约定也不同。Unity通常使用OpenGL风格的“纹理V坐标向上”，而UE4使用DirectX风格的“纹理V坐标向下”。这个V坐标的差异，在切线空间计算中，会最终体现为法线贴图绿色通道（G）的取反。所以，在实践中，Unity和UE4的法线贴图转换，核心操作往往是对绿色通道（G）进行G' = 1 - G的翻转。蓝色通道（B）有时也需要调整，取决于贴图的来源和压缩设置。我们的转换脚本将处理这两种情况。

2.3 生产管线中的连锁反应

这个底层差异像涟漪一样扩散到整个美术生产管线：

1. 烘焙软件设置：在使用Substance Painter、Marmoset Toolbag或xNormal烘焙法线贴图时，必须指定目标引擎。选“Unity”还是“UE4”，软件内部就会应用不同的Y轴（或Z轴）方向处理。
2. 引擎导入设置：Unity和UE4的纹理导入器都提供了“翻转Y（Green）通道”或“转换为DX格式”之类的选项，就是为了兼容不同来源的贴图。
3. 压缩格式：一些针对法线贴图优化的压缩格式（如BC5，在Unity中叫DXT5nm）会利用这种通道存储特性。BC5格式只存储X（R）和Y（A）通道，而Z通道由着色器实时计算Z = sqrt(1 - X² - Y²)。如果原始数据的Y通道方向不对，压缩后问题依旧。
4. 资源商店资产：从Unity Asset Store或Unreal Marketplace购买的模型资产，其附带的法线贴图通常是针对该引擎预处理好的。直接跨引擎使用，十有八九会出问题。

理解了这个原理，我们就从“遇到问题瞎调试”进入了“有的放矢去解决”的层面。接下来，我们看看如何在实际操作中应对。

3. 手动检查与引擎内置解决方案

在动用转换脚本之前，了解如何在引擎内进行诊断和初步修复是很有必要的。这能帮你快速判断问题所在，并在一些简单场景下直接解决。

3.1 在Unity中诊断与修复“UE4风格”法线贴图

当你把一张疑似为UE4准备的法线贴图导入Unity后，如果模型光照看起来是反的，可以按以下步骤操作：

1. 视觉检查：在Project窗口选中法线贴图，在Inspector预览窗口，将纹理预览从“Default”切换到“Normal map”。观察贴图整体颜色。一张为Unity准备的法线贴图，平坦区域通常偏蓝紫色（因为B通道值高，R和G通道值接近中性）。如果一张贴图平坦处偏蓝绿色或颜色明显不对劲，很可能它就是“反”的。
2. 导入设置修正：在法线贴图的Import Settings中，找到“Texture Type”为“Normal map”的配置区域。关键参数是“Bumpiness”滑块下方的“Create from Grayscale”选项，以及更重要的——“sRGB (Color Texture)”选项。
   • sRGB选项：法线贴图绝对不是sRGB纹理！必须取消勾选“sRGB (Color Texture)”。因为法线数据是线性数据，不是颜色信息。启用sRGB会导致引擎对纹理数据进行错误的伽马校正，严重破坏法线向量的准确性。
   • 高级选项：在“Advanced”下拉菜单中，你会看到“Fixup edge seams”和“Filtering”等选项。对于法线贴图，Filtering模式建议使用“Normal map”，这个模式会使用特殊的滤波算法来避免在法线贴图Mipmap时引入错误。
3. 使用“翻转”功能：Unity的纹理导入器提供了一个直接的修复选项。在Import Settings的“Normal map”部分，勾选“Flip Vertically (Y-axis)”（或类似名称，不同Unity版本可能表述为“Convert from DX Normals”）。这个操作本质上就是对绿色通道(G)进行G' = 1 - G的数学变换。勾选后应用(Apply)，观察模型上的光照效果是否恢复正常。
4. 着色器图形检查：如果你使用Shader Graph或编写自定义着色器，确保法线贴图采样后，正确地使用UnpackNormal或UnpackNormalRGB函数（对于DXT5nm压缩格式用UnpackNormal，对于RGB法线用UnpackNormalRGB）。这些内置函数包含了平台相关的处理，能自动处理一些通道差异。

实操心得：在Unity中，一个快速验证法线方向的方法是，创建一个默认的Standard Shader材质球，将法线贴图赋给它，然后将其拖到一个简单的Sphere或Plane上。观察高光点的移动。用手电筒（平行光）从侧面照射，缓慢旋转灯光或模型。如果凹凸感随着光照方向变化而“反直觉”（例如，光从左边来，右侧却更亮），那基本可以确定法线方向需要翻转。

3.2 在UE4/UE5中诊断与修复“Unity风格”法线贴图

在Unreal Engine中，流程类似，但界面和术语有所不同。

1. 视觉检查：在Content Browser中选中法线贴图，在纹理预览器的左下角，将视图模式从“Color”切换到“Normal Map”。同样观察颜色。UE4期望的法线贴图在平坦区域通常呈现一种“偏紫红色”的感觉（因为B通道值低，R通道值中等，这是DX格式的特点）。如果导入的图偏蓝，那很可能来自Unity。
2. 纹理资产设置：双击打开纹理资产，查看其“Texture”属性组。最关键的两个设置是：
   • sRGB：和Unity一样，必须设置为关闭（False）。这是新手最常犯的错误之一，把法线贴图当颜色贴图导入，导致渲染一片漆黑或效果怪异。
   • Compression Settings：必须设置为“Normalmap”。这个设置不仅会选择适合法线数据的压缩算法（如BC5），还会在压缩时进行一些必要的重新规范化处理，保证法线向量的长度始终为1。
3. 材质编辑器中的修复：如果导入的纹理是Unity格式，最常见的修复方法是在材质蓝图（Material Graph）中，对采样到的法线向量进行处理。
   • 连接Texture Sample节点的RGB输出到一个“FlattenNormal”节点（这实际上是一个小技巧）。
   • 更直接的方法是使用一个“Custom Node”或函数，编写一行HLSL代码：float3 FixedNormal = float3(Normal.r, 1.0 - Normal.g, Normal.b);这行代码翻转了绿色通道。
   • 或者，使用“Transform”节点，将法线从“Tangent Space”转换到“World Space”或“Local Space”时，某些设置也可能隐含了修正。
4. 导入时批量处理：对于大量资产，更好的办法是在导入前或导入时进行转换。UE4的纹理导入选项里，有一个“Flip Green Channel”的选项（可能位于高级设置中）。勾选此选项，引擎在导入时就会自动对绿色通道进行翻转。

注意事项：在UE4/UE5中，如果法线贴图用于“Default Lit”着色模型，引擎内部已经包含了大量的自动处理。有时，即使贴图来源是Unity，只要“sRGB”关闭且“Compression”设为“Normalmap”，引擎也能通过内部转换得到近似正确的结果，但可能不完美。最可靠的方法还是在DCC（数字内容创作）工具或通过脚本进行源头转换。

手动修复对于单张贴图或临时调试是可行的，但面对成百上千张资源时，效率低下且容易出错。因此，一个自动化、可批量处理的一键转换脚本，就成了跨引擎生产管线中不可或缺的工具。

4. 一键转换脚本的深度解析与实现

下面我将提供一个功能完善、鲁棒性强的Python脚本，它使用PIL（Pillow）库来处理图像，实现Unity与UE4法线贴图的互转。我将逐部分解释其设计思路和关键代码。

4.1 脚本完整代码与依赖

首先，确保你已安装Python和Pillow库。可以通过pip安装：pip install Pillow

#!/usr/bin/env python3 """ Unity <-> UE4 法线贴图一键转换脚本 功能：在Unity格式（OpenGL风格）和UE4格式（DirectX风格）的法线贴图之间相互转换。 核心操作：翻转绿色通道（G），并可选择性地重新计算或翻转蓝色通道（B）。 """ import os import sys import argparse from PIL import Image import numpy as np def convert_normal_map(image_path, output_path, to_unity=True, fix_blue=True, overwrite=False): """ 转换单张法线贴图。 参数: image_path (str): 输入图片路径。 output_path (str): 输出图片路径。 to_unity (bool): True表示转换为Unity格式，False表示转换为UE4格式。 fix_blue (bool): 是否修复蓝色通道（基于新的绿色通道重新计算Z）。推荐保持True。 overwrite (bool): 是否覆盖已存在的输出文件。 """ # 1. 检查输出路径 if not overwrite and os.path.exists(output_path): print(f"警告：输出文件已存在 '{output_path}'。使用 --overwrite 参数覆盖。") return False try: # 2. 打开并验证图像 img = Image.open(image_path) if img.mode not in ('RGB', 'RGBA'): # 有些法线贴图可能是灰度图或其他格式，尝试转换 print(f"信息：图像模式为 '{img.mode}'，正在转换为 'RGBA'...") img = img.convert('RGBA') else: img = img.convert('RGBA') # 统一在RGBA空间处理，保留Alpha通道（可能用于其他数据） data = np.array(img, dtype=np.float32) / 255.0 # 归一化到[0,1] # 3. 分离通道 R = data[:, :, 0] G = data[:, :, 1] B = data[:, :, 2] A = data[:, :, 3] if data.shape[2] == 4 else np.ones_like(R) # 处理3通道情况 # 4. 核心转换逻辑：翻转绿色通道 # 从存储值还原法线分量：normal = (color * 2) - 1 # 翻转Y分量：new_normal_y = -normal_y # 转换回存储值：new_color_g = (new_normal_y * 0.5) + 0.5 = 1 - color_g # 所以，直接对绿色通道存储值进行 1-G 操作即可。 G_new = 1.0 - G # 5. 处理蓝色通道（可选但推荐） B_new = B if fix_blue: # 原理：法线向量是单位向量，满足 X² + Y² + Z² = 1 # 存储值 color = (normal * 0.5) + 0.5 # 因此，normal_z = 2 * (color_b - 0.5) # 当翻转Y后，为了保证向量仍是单位向量，需要根据新的X和Y重新计算Z。 # 但更简单且常见的做法是：假设原始贴图是合法的单位向量贴图， # 翻转Y后，Z的符号可能需要反转，或者直接取 sqrt(1 - X² - Y²)。 # 这里采用一种稳健的方法：如果原始B通道主要用于存储Z（通常是的）， # 在翻转Y后，我们反转蓝色通道的“变化趋势”，即 B_new = 1 - B。 # 这对于大多数从标准烘焙软件导出的、未压缩的RGB法线贴图是有效的。 # 注意：对于DXT5nm等特殊压缩格式，此脚本不直接适用。 print(f"信息：正在根据新的绿色通道调整蓝色通道...") # 方法1：简单反转（适用于很多情况） # B_new = 1.0 - B # 方法2：重新计算Z（更精确，但可能改变原始数据意图，如手绘法线） # 从存储值还原X,Y normal_x = (R * 2.0) - 1.0 normal_y_old = (G * 2.0) - 1.0 normal_y_new = (G_new * 2.0) - 1.0 # 翻转后的Y # 计算旧的Z，用于判断符号 normal_z_old = (B * 2.0) - 1.0 # 计算新的Z幅值（正数） magnitude_squared = normal_x**2 + normal_y_new**2 # 防止开方负数（由于浮点误差） magnitude_squared = np.clip(magnitude_squared, 0.0, 1.0) new_z_magnitude = np.sqrt(1.0 - magnitude_squared) # 保持Z分量的原始符号？不，在翻转Y后，Z的符号逻辑复杂。 # 更安全的做法：让新的Z为正（指向外部），这是Unity/OpenGL的约定。 # 但为了兼容性，我们采用一个启发式方法：如果旧Z的绝对值很大，我们保留其方向感？ # 实际上，对于标准切线空间法线贴图，平坦处Z应接近1或-1。 # 我们根据目标平台决定符号： # 转换为Unity（OpenGL）：Z应为正 -> 存储值 > 0.5 # 转换为UE4 (DirectX)：Z应为负 -> 存储值 < 0.5 target_z_sign = 1.0 if to_unity else -1.0 normal_z_new = new_z_magnitude * target_z_sign B_new = (normal_z_new * 0.5) + 0.5 B_new = np.clip(B_new, 0.0, 1.0) # 确保在有效范围内 # 6. 根据转换方向，决定最终输出的通道数据 # to_unity=True: 目标格式是Unity (OpenGL)，我们当前已翻转了G（假设输入是UE4格式）。 # to_unity=False: 目标格式是UE4 (DirectX)，我们当前已翻转了G（假设输入是Unity格式）。 # 所以核心操作就是翻转G，B通道根据fix_blue参数调整。 # 红色通道(R)和Alpha通道(A)通常保持不变。 # 但有一种情况：如果输入贴图已经是目标格式，再翻转一次G就错了。 # 脚本假设你明确知道输入贴图的源格式，并通过to_unity参数指定目标格式。 # 例如：输入是UE4格式，想转Unity，则设置 to_unity=True。 output_data = np.zeros_like(data) output_data[:, :, 0] = R output_data[:, :, 1] = G_new # 翻转后的绿色通道 output_data[:, :, 2] = B_new # 调整后的蓝色通道 output_data[:, :, 3] = A # 保留Alpha # 7. 将数据转换回0-255整数范围并保存 output_data = (np.clip(output_data, 0.0, 1.0) * 255.0).astype(np.uint8) output_img = Image.fromarray(output_data, 'RGBA') # 根据输出路径后缀决定保存格式，尽量保留Alpha output_img.save(output_path) print(f"成功：已转换 '{image_path}' -> '{output_path}' (目标: {'Unity' if to_unity else 'UE4'})") return True except Exception as e: print(f"错误：处理 '{image_path}' 时失败: {e}") return False def batch_convert(input_dir, output_dir, to_unity=True, fix_blue=True, overwrite=False, ext=('.png', '.jpg', '.jpeg', '.tga', '.bmp')): """ 批量转换目录下的法线贴图。 """ if not os.path.exists(input_dir): print(f"错误：输入目录不存在 '{input_dir}'") return os.makedirs(output_dir, exist_ok=True) converted = 0 failed = 0 for root, dirs, files in os.walk(input_dir): for file in files: if file.lower().endswith(ext): # 常见法线贴图命名包含‘normal’, ‘nrm’, ‘n’, ‘_n’等，可以进行过滤。 # 这里为了通用性，转换所有匹配扩展名的图片。用户可自行过滤。 input_path = os.path.join(root, file) # 保持输入目录结构 rel_path = os.path.relpath(input_path, input_dir) output_path = os.path.join(output_dir, rel_path) os.makedirs(os.path.dirname(output_path), exist_ok=True) if convert_normal_map(input_path, output_path, to_unity, fix_blue, overwrite): converted += 1 else: failed += 1 print(f"\n批量转换完成。成功：{converted} 张，失败：{failed} 张。") def main(): parser = argparse.ArgumentParser(description='Unity与UE4法线贴图转换工具') parser.add_argument('input', help='输入图片路径或目录路径') parser.add_argument('output', help='输出图片路径或目录路径') parser.add_argument('--to-unity', action='store_true', default=True, help='转换为Unity格式 (OpenGL风格)。这是默认选项。') parser.add_argument('--to-ue4', action='store_false', dest='to_unity', help='转换为UE4格式 (DirectX风格)。') parser.add_argument('--no-fix-blue', action='store_false', dest='fix_blue', default=True, help='不重新计算蓝色通道（仅翻转绿色通道）。') parser.add_argument('--overwrite', action='store_true', default=False, help='覆盖已存在的输出文件。') parser.add_argument('--batch', action='store_true', default=False, help='批量模式。input和output应为目录路径。') args = parser.parse_args() if args.batch: batch_convert(args.input, args.output, args.to_unity, args.fix_blue, args.overwrite) else: convert_normal_map(args.input, args.output, args.to_unity, args.fix_blue, args.overwrite) if __name__ == '__main__': main()

4.2 脚本核心逻辑与参数详解

这个脚本的设计遵循了“清晰、稳健、可配置”的原则。

1. 核心转换算法 (convert_normal_map函数)：

   • 绿色通道翻转：无论采用哪种更精确的后续处理，最核心、最必要的操作都是G_new = 1.0 - G。这直接对应了切线空间Y轴方向的取反。
   • 蓝色通道处理 (fix_blue参数)：这是一个进阶选项。为什么需要处理蓝色通道？因为法线向量是单位向量。当你改变了Y分量，为了保持向量长度仍为1，Z分量理论上应该重新计算。脚本提供了两种策略：
     • 简单反转 (B_new = 1.0 - B)：对于绝大多数从标准烘焙流程产出的、未压缩的RGB法线贴图，这种方法简单有效，且能保持贴图的视觉连续性。它基于一个经验假设：原始贴图的蓝色通道变化与绿色通道存在某种对称关系。
     • 重新计算Z：这是更数学严谨的方法。脚本根据翻转后的新X和Y分量，利用公式Z = sqrt(1 - X² - Y²)重新计算Z的幅值，然后根据目标平台（Unity需要Z为正，UE4需要Z为负）赋予符号。这种方法更精确，但可能对手绘法线贴图或经过特殊处理的贴图产生非预期影响，因为手绘贴图可能不严格遵守单位向量的物理约束。
   • 默认推荐：fix_blue=True并使用重新计算Z的方法。这能保证转换后的法线向量在数学上是正确的单位向量，避免因通道不匹配可能导致的细微光照瑕疵。

2. 关键参数解析：

   • --to-unity/--to-ue4：你必须明确知道输入贴图的当前格式和目标格式。例如，你从Substance Painter以“UE4”预设烘焙了一张图，现在想用在Unity里，那么输入格式是UE4，目标格式是Unity，你应该使用--to-unity（默认）。脚本的逻辑是“将贴图转换到目标格式”，它假设你对输入格式的判断是正确的。
   • --no-fix-blue：如果你确信你的法线贴图蓝色通道只存储了Z分量的绝对值信息（例如某些特殊的压缩流或引擎内部格式），或者转换后出现奇怪的色偏，可以尝试关闭蓝色通道修复，仅翻转绿色通道。这通常作为问题排查的一个步骤。
   • --batch和--overwrite：生产力工具必备。--batch允许你处理整个文件夹，保持目录结构。--overwrite则避免因文件已存在而频繁报错。

3. 图像处理细节：

   • 脚本使用PIL库的RGBA模式处理，能保留Alpha通道。有些法线贴图的Alpha通道可能存储了高度图（Height Map）或其他信息，保留它是好的做法。
   • 所有像素计算都在归一化的浮点数范围[0.0, 1.0]内进行，避免整数运算的精度损失。
   • 使用了np.clip来防止计算过程中出现超出[0,1]范围的无效值，确保输出图像的稳定性。

4.3 如何使用这个脚本

假设你的脚本保存为normal_map_converter.py。

场景一：单张贴图转换你有一张为UE4制作的法线贴图rock_normal_ue4.png，想在Unity中使用。

python normal_map_converter.py rock_normal_ue4.png rock_normal_unity.png --to-unity

（--to-unity是默认参数，可省略）。

场景二：批量转换整个文件夹你的Assets/Textures/UE4_Normals文件夹下全是UE4格式的法线贴图，你需要批量转换为Unity格式，输出到Assets/Textures/Unity_Normals。

python normal_map_converter.py Assets/Textures/UE4_Normals Assets/Textures/Unity_Normals --to-unity --batch --overwrite

场景三：将Unity格式转回UE4格式你从Unity项目里拿到一张法线贴图，需要用在UE4项目中。

python normal_map_converter.py character_normal_unity.tga character_normal_ue4.tga --to-ue4

实操心得：在使用脚本前，强烈建议先备份原始贴图，并用单张图测试效果。转换后，在引擎中创建一个简单的测试材质和模型，用平行光照射并旋转观察，确保凹凸方向符合预期。对于具有明显方向性的特征（如划痕、浮雕文字），这是最好的检验方法。

5. 常见问题、排查技巧与进阶考量

即使有了自动化脚本，在实际工作流中你仍可能遇到各种边界情况。下面是一些常见问题的排查思路和进阶知识。

5.1 转换后效果仍然不对？

如果按照上述方法转换后，模型光照还是奇怪，可以按以下步骤排查：

1. 确认贴图类型：首先百分之百确认你操作的纹理是法线贴图，而不是高度图、视差贴图、环境光遮蔽贴图或其他。这些贴图看起来可能类似，但转换它们会彻底破坏数据。
2. 检查引擎导入设置：这是最常被忽略的一步。脚本转换了图片数据，但引擎的纹理导入设置如果错了，会再次“扭曲”数据。务必确认：
   • Unity：Texture Type = Normal map；sRGB =Off；必要时勾选/取消“Flip Vertically”。
   • UE4：sRGB =False；Compression Settings =Normalmap。
3. 检查材质/着色器：材质球是否正确连接了法线贴图？着色器是否使用了正确的法线输入节点和Unpack函数？在Unity中，Standard Shader会自动处理；在UE4中，确保连接到“Normal”引脚，而不是“Base Color”或其他。
4. 验证转换方向：你可能搞反了--to-unity和--to-ue4。用一个极端案例测试：找一张颜色均匀偏蓝紫色（Unity格式）或偏紫红色（UE4格式）的纯色法线贴图（代表平坦表面），转换后观察其主色调变化。Unity转UE4，蓝色应减少，红色/紫色感增加。
5. 压缩格式干扰：如果你的贴图是.dds格式并使用BC5（DXT5NM）压缩，这个脚本可能不直接适用。BC5格式存储的是X和Y在另外两个通道，Z是计算得出的。对于这种格式，通常需要在DCC工具或引擎中设置正确的“翻转绿色”选项，或者使用支持BC5格式的专业工具进行转换。

5.2 不同来源资产的特殊处理

• 来自Substance Painter：在导出时，直接选择正确的目标引擎模板（“Unity”或“Unreal Engine”），这是最源头、最干净的解决方案。
• 来自xNormal或Marmoset Toolbag：在烘焙设置中，明确指定法线贴图的“Y轴方向”（OpenGL还是DirectX）。
• 来自网络下载的通用资产：通常需要手动转换。使用我们的脚本是一个好起点。
• 移动平台与压缩：对于移动平台，为了节省内存带宽，法线贴图常被压缩。ASTC压缩格式在Unity和UE4中都有很好的支持，且通常不涉及这种Y轴翻转问题，因为压缩/解压是引擎内部处理的。关键在于给引擎的源数据（压缩前）格式要正确。

5.3 性能与管线集成建议

对于大型项目，手动或脚本批量转换只是权宜之计。更专业的做法是将格式转换集成到你的资产流水线（Asset Pipeline）中。

1. 编写编辑器脚本：在Unity中，可以编写一个Editor脚本，监听PostProcessTexture事件，当导入纹理时，根据命名规则（如*_N_UE4.*）自动进行通道翻转并覆盖导入设置。在UE4中，可以编写Import模块的插件或使用Python脚本进行自动化处理。
2. 使用中间格式：在团队协作中，可以约定所有原始美术资产都输出为一种“中性”格式（例如，约定切线空间Z轴向外），然后在引擎的导入阶段，通过引擎各自的导入设置（Unity的翻转选项，UE4的翻转选项）来适配。这样DCC工具只需输出一种版本。
3. 版本控制：转换后的贴图应与原始贴图分开存储，并明确命名（如*_Unity.*,*_UE4.*），避免混淆。在.gitignore或版本控制系统中设置好规则。

5.4 法线贴图的其他“坑”

除了Y轴翻转，法线贴图还有其他需要注意的地方：

• 切线空间 vs 对象空间：本文讨论的都是切线空间法线贴图，这是最常用的类型。还有一种对象空间法线贴图，其法线方向是基于模型整体坐标的，不存在引擎间的这种翻转问题，但它不能用于变形动画（如蒙皮），且复用性差。
• 镜面对称UV：对于对称模型（如角色），美术师常使用镜面对称的UV来节省空间。这时，一侧的法线贴图在镜像后，其切线空间的X方向会反转，需要在引擎着色器中或烘焙时进行额外的“切线向量镜像”处理，否则接缝处光照会不连续。
• 打包与精度：将法线贴图与粗糙度、金属度等贴图打包到一张图的RGBA通道中，是常见的优化手段。这时要确保法线通道（通常是RG）的转换正确，且sRGB设置关闭。

理解Unity和UE4法线贴图的差异，远不止于解决一个“图片反了”的问题。它像一扇窗户，让你窥见实时渲染领域因历史路径依赖而产生的技术碎片化，以及图形API标准对上层工具链的深远影响。作为开发者或技术美术，掌握这种底层原理和转换技能，能让你在跨引擎协作、资产管理和性能优化上更加游刃有余。下次再遇到法线问题，希望你能自信地说：“小样，不就是坐标系那点事儿嘛。”