简介RenderDocV1.x批量导出纹理版是基于RenderDoc二次开发的图形调试增强工具面向游戏研发、图形编程及渲染分析人员解决原生版本只能逐个导出纹理、流程繁琐、耗时明显的问题。修改版通过扩展RenderDoc接口、遍历帧内纹理资源并引入多线程与多种常见格式支持把大量纹理的导出工作压缩为批量操作尤其适合贴图量大或需要周期性做资源审计的项目。压缩包共51个文件约51.6MB核心由29个dll动态库、6个exe执行程序、6个pyd扩展模块组成同时带有多份头文件与json配置并内置Qt/Python运行组件和x86/x64两套Release版本。包内同时提供图形界面与命令行可执行程序解压后可按环境选用直接用于帧纹理的批量提取和保存。已有1186人学习下载适合需要快速获取帧纹理、整理贴图资源或排查渲染问题的开发者收藏参考。1. 批量导出纹理这回事先把场景说清楚做帧调试的人都有这种经历RenderDoc V1.x里打开一个捕获场景里二三十张纹理等着逐个过目。右键一张张Export点到后面手酸还经常漏点。RenderDoc V1.x批量导出纹理版解决的就是这个写一段脚本把捕获里所有纹理按你定的命名规则、格式和层级一次性落到磁盘。这套做法适合三种人一是做渲染调试时要把帧里所有资源归档的开发者二是技术美术需要把美术资源在实时渲染里的终版效果导出来核对三是做自动化比对的人想拿不同帧的纹理做像素级diff。前提是你对RenderDoc的基本操作已经顺手但不想继续忍受机械重复。目标是让脚本帮你把“看完一张导出一次”变成“跑一条命令全部拿到”。2. 导出前必须搞清的三个概念资源、纹理与保存格式批量导出脚本的核心逻辑是“遍历描述 → 选格式 → 落盘”。如果不知道RenderDoc用什么结构描述一张纹理参数就只能靠猜导出的结果就会各种不对劲。这章先讲概念再给选型。2.1 RenderDoc眼里的纹理不只是一张图片在RenderDoc的回放环境里每个纹理资源对应一个唯一的ResourceId同时附带一份TextureDescription结构体。脚本里调用GetTextures()返回的就是这些描述对象的列表。字段大概包括width、height、depth是基础尺寸mips是mip层级数arraySize是数组层数type区分Texture1D、Texture2D、Texture2DArray、Texture3D、Cubeformat是ResourceFormat里面有compTypeFloat、UNorm、UInt、Depth等和compCount。批量导出最容易漏掉的就是arraySize和mips。UI右键导出时RenderDoc默认帮你导了“当前看得见的那一层”脚本没有这个默认值。你不处理CubeMap只拿到第一个面数组纹理只拿到第一层。这也是后面避坑章节的伏笔。format字段决定了你用什么格式落盘。比如format是BC7的压缩纹理RenderDoc在导出PNG时会自动解压如果你走原始数据读取再自己编码就得先解压BC7块这活儿自己做起来相当痛苦。所以脚本导出时尽量别自己碰原始字节交给RenderDoc的保存接口。2.2 三种导出姿势UI右键、离线脚本、内嵌控制台常见的导出姿势有三种。UI右键导出适合临时看一两张它把当前资源通道、当前mip、当前面的那一份存下来优点是直观缺点是没法批量。renderdoccmd是RenderDoc自带命令行工具可以回放捕获但它的职责更多在捕获、回放和自动化测试拿来做灵活导出不如脚本顺手。最可控的是Python接口能拿到完整描述、能做过滤、能循环、能重试出了错还能打日志。方式适用场景批量能力可定制性UI右键导出临时看一两张纹理弱低renderdoccmd捕获、回放、回归测试中中Python脚本批量导出、归档、像素比对强高我一般会直接用Python接口。RenderDoc安装目录里自带Python接口模块够用脚本跑在哪个环境不重要重要的是先把接口跑通。V1.x的接口整体稳定但小版本之间偶尔有枚举名和函数签名的漂移遇到问题先查本机版本的接口签名别上来就怀疑逻辑。2.3 导出格式怎么选PNG、DDS、KTX、EXR脚本里最难定的不是逻辑是格式。批量导出前先想清楚这批纹理给谁看。导出一份用于核对的纹理我习惯PNG导出给引擎侧用的DDS或KTX发现纹理里存了float数据比如GBuffer里的深度/法线用EXR才能保证不丢精度。格式典型场景是否保留mip备注PNG文档、验收、像素比对否无损适合RGBA8DDS回拷引擎、工具链是能保留压缩块信息KTX移动端、运行时加载是需要配套解析库EXRHDR、float纹理否保存高动态范围TextureSave里通过format字段指定目标格式比如FileType.PNG、FileType.DDS、FileType.KTX、FileType.EXR。不同格式会直接影响保存接口内部走的编码路径所以“先定格式再写循环”是对的。另外还要理解TextureSave这个配置对象它管的不只是格式还有mip、slice、目的位置磁盘还是内存缓冲。批量脚本里常用的是把destination设为Disk直接落盘。3. 用Python脚本把批量导出跑通最小可用版现在开始动手。这章给一个能直接用的最小脚本然后拆开讲参数含义。跑通之后再做命名、过滤和重试这些工程化的事。3.1 最小脚本遍历纹理、逐个落盘import renderdoc as rd import os def export_all_textures(capture_path: str, output_dir: str) - int: # 初始化RenderDoc运行时 rd.Initialise() # 打开捕获文件并加载 controller rd.ReplayController.OpenCaptureFile(capture_path) if controller is None: raise RuntimeError(无法打开捕获文件: %s % capture_path) err controller.LoadCapture() if err ! 0: raise RuntimeError(加载捕获失败错误码: %d % err) # 遍历所有纹理资源 textures controller.GetTextures() os.makedirs(output_dir, exist_okTrue) for tex in textures: # tex 是 TextureDescriptionresourceId 唯一标识资源 out_path os.path.join(output_dir, f{tex.resourceId}.png) result controller.SaveTexture(tex.resourceId, out_path) print(f{tex.resourceId} {tex.width}x{tex.height} - {out_path} ({result})) controller.Shutdown() rd.Shutdown() return 0 if __name__ __main__: export_all_textures(frame_0123.rdc, exported_textures)这个脚本的逻辑很直白初始化RenderDoc打开捕获文件加载回放拿全部纹理描述循环保存成PNG。SaveTexture第一个参数是ResourceId第二个参数是落盘路径。这里没有指定mip和slice默认保存的是“可用视图”对应的那一层对于普通Texture2D够用了。脚本末尾的Shutdown不能省批量跑多个捕获文件时不释放回放控制器会累积显存和内存。跑之前有两件事要确认一是确保Python能找到renderdoc模块常见做法是在RenderDoc安装目录里找到Python接口模块路径或者直接用RenderDoc UI自带的内嵌控制台跑省掉sys.path的折腾二是确认捕获文件是用匹配的V1.x版本生成的版本跨太大的文件打不开或者加载报错。3.2 参数怎么调整mip层、数组切片、目标目录最小脚本导出的是“默认层”但真实场景里你得控制导出哪一层mip、哪一层数组切片、命名带什么后缀。这就需要TextureSave对象def export_with_options(controller, tex, output_dir): # 构造保存选项 opts rd.TextureSave() opts.format rd.FileType.PNG opts.mip 0 # 只导出第0层mip opts.slice 0 # 数组/立方体贴图的第0层 opts.destination rd.TextureSaveDestination.Disk out_path os.path.join(output_dir, f{tex.resourceId}_m0.png) # 带选项的保存不同小版本对tex参数的传法略有差异 controller.SaveTexture(tex.resourceId, out_path, opts)mip参数控制mip层级0是最高分辨率那一层tex.mips - 1是最小的一层。slice参数在普通Texture2D上无效但在Texture2DArray和Cube上就是决定生死的关键。Cube纹理的arraySize通常是6每个面一个slice遍历时要把slice从0循环到5才能导出完整天空盒。destination设为Disk表示直接写文件如果后续要对纹理数据做二次处理可以改成MemoryBuffer从返回的字节数组自己处理。这里要特别提一下SaveTexture在不同小版本里的签名差异。V1.x早期版本有的要求传(resourceId, path)有的版本传(resourceId, path, opts)还有的版本把path放进了opts.destination。写通用脚本时用hasattr或者try/except包一层别把签名写死。用dir(controller.SaveTexture)看本机版本的签名比翻文档快。3.3 从UI里验证脚本结果和手点导出一致脚本跑完先别急着批量使用选一张纹理做一致性校验。在RenderDoc UI里找到同一个ResourceId的纹理右键Export成PNG然后用文件比对工具对比UI导出文件和脚本导出文件。理论上同一版本、同一导出格式、同一mip和slice两份文件的像素数据应该完全一致。我习惯用md5做快速校验md5sum ui_export.png script_export.png。如果md5一致说明脚本走的路子和UI一致可以信任批量结果如果不一致先检查导出的mip和slice是否一致再看是不是文件名里带了不同的后缀。UI右键导出时RenderDoc也遵循同样的TextureSave逻辑出现不一致大概率是你脚本里设置了UI没有的设置项比如mip不是0。4. 把脚本改成能每天用的工具命名、过滤和错误处理最小脚本能跑通但要天天用还差得远。原始文件名是resourceId数字串看不出哪张是哪张捕获里还混着一堆1x1像素的占位纹理和buffer导出来纯属噪音。这章把脚本往工具方向推。4.1 命名规则加尺寸、格式、层级别用resourceId裸奔resourceId做文件名有一个好处是唯一但可读性为零。你在项目里看到一个1234567890.png根本不知道它对应的是漫反射还是法线。我常用的命名规则是把纹理名、尺寸、格式和层级拼在一起def build_name(tex, mip_idx0, slice_idx0): fmt_name tex.format.shortName() if hasattr(tex.format, shortName) else str(tex.format) base tex.name if tex.name else str(tex.resourceId) return f{base}_{tex.width}x{tex.height}_{fmt_name}_m{mip_idx}_s{slice_idx}.png纹理的name字段在捕获里不一定有很多内部资源名是空的。这时用resourceId兜底至少保证不重名。shortName方法把R8G8B8A8_UNORM压缩成可读性好的短名比打一串全称好。带上mip和slice后缀是为了避免同一纹理不同层导出时互相覆盖。最后清理文件名里的非法字符把空格换成下划线去掉路径分隔符否则在部分平台上写文件会报错。4.2 过滤逻辑只导关心的事件期间的纹理一帧捕获里的纹理资源数量比你想的多。RenderDoc的GetTextures()返回所有分配过的纹理包括1x1的占位纹理、深度缓冲、staging纹理。你真正关心的可能是几张主场景纹理所以过滤逻辑要加for tex in textures: # 跳过buffer类型 if tex.type rd.TextureType.Buffer: continue # 跳过过小的纹理 if tex.width 16 and tex.height 16: continue # 跳过明显是占位符的无名资源 if not tex.name and tex.width 4: continue # 导出 opts rd.TextureSave() opts.format rd.FileType.PNG opts.mip 0 opts.slice 0 opts.destination rd.TextureSaveDestination.Disk out_path os.path.join(output_dir, build_name(tex)) controller.SaveTexture(tex.resourceId, out_path, opts)过滤条件按需增减。比如调试GBuffer时反而要导深度纹理这时就别按维度过滤而是按compType过滤把Depth类型单独挑出来导EXR。常见做法是先跑一次全量导出py文件里打印每个纹理的name、type、format、尺寸看一遍再定过滤规则。第一次别太自信先看全貌再砍数据。4.3 断点续导与失败重试批量导出几十张纹理时中途可能因为磁盘空间不足、单个纹理过大、驱动超时等问题中断。重新从头跑一遍浪费时间所以断点续导是刚需。我通常维护一个文本清单记录已完成导出的文件路径manifest_path os.path.join(output_dir, exported.txt) done set() if os.path.exists(manifest_path): with open(manifest_path, r, encodingutf-8) as fp: done.update(line.strip() for line in fp if line.strip()) for tex in textures: out_path os.path.join(output_dir, build_name(tex)) if out_path in done: continue for attempt in range(2): try: controller.SaveTexture(tex.resourceId, out_path, opts) with open(manifest_path, a, encodingutf-8) as fp: fp.write(out_path \n) break except Exception as e: print(f第{attempt 1}次导出失败: {tex.resourceId} - {e})这个做法的关键是“先写清单再继续下一个”确保导出成功的文件一定被记录。失败重试两次就放弃避免死循环。清单文件本身也方便你事后统计哪些纹理成功、哪些失败、失败原因是什么。配合上一条的打印日志基本能定位所有问题。5. 批量导出纹理避坑实录现象、原因与解决脚本跑多了总会遇到玄学问题。这章写五个我实际踩过的坑按“现象 → 原因 → 解决”记录给后来者少烧点时间。5.1 黑图翻车压缩纹理没有正确解压就落盘现象导出的PNG完全黑或者大面积花屏但RenderDoc UI里预览却正常。第一次遇到以为是显存损坏吓一跳。原因部分纹理在驱动侧是块压缩格式BC1/BC3/BC7RenderDoc的预览视图会做解压显示但脚本直接读取原始数据时拿到的是压缩块。后续保存为PNG时如果代码路径里没有触发解压就会把压缩数据当像素数据编码得到黑图和花屏。解决把导出交给SaveTexture并明确指定目标格式。RenderDoc在保存为PNG/DDS/EXR时会按目标格式自动处理源纹理的压缩状态。千万不要自己用GetTextureData拿字节缓存再交给PIL之类的库编码除非你明确知道自己在解压BC块。另外导出时留意tex.format.blockSize字段看到blockSize大于0的格式优先用SaveTexture而不是手写编码路径。5.2 数组纹理和CubeMap只导出第一层现象CubeMap纹理导出的PNG只有第一个面的内容另外五个面凭空消失数组纹理导出的结果只有slice 0。原因SaveTexture默认的slice参数是0UI右键导出时会自动按当前选中的面处理脚本没有这个默认必须显式循环。解决判断tex.arraySize或tex.type。Cube类型的arraySize在RenderDoc里通常表现为6写循环时不要用arraySize硬编码按type判断更稳妥if tex.type rd.TextureType.Cube: slice_count 6 elif tex.type rd.TextureType.Texture2DArray: slice_count tex.arraySize else: slice_count 1 for slice_idx in range(slice_count): opts.slice slice_idx out_path ... # 带slice后缀 controller.SaveTexture(tex.resourceId, out_path, opts)5.3 Windows下中文路径导出0字节现象脚本没报错输出目录也生成了文件但文件大小是0。单独查文件名发现路径里带中文或者空格比如D:\测试输出\water map.png。原因V1.x部分版本的底层文件写入用了窄字符路径在Windows上遇到非ASCII字符时写文件失败但上层接口没有把错误透传出来静默产出0字节文件。解决全ASCII输出目录文件名里不要留中文。路径中的空格尽量换成下划线。这是一个干脆的规避方案——为验证工具折腾宽字符路径编码不值得。同时加一道防线保存后立即检查文件大小等于0就视为导出失败打印警告并计入失败清单。这样即使遇到其他路径编码问题也不会静默通过。5.4 在action循环里到处调SaveTexture导致重复导出几十次现象导出的文件数量比预期多一个数量级同一张纹理出现几十次只是名字后缀不同。原因遍历渲染动作列表action tree时每个draw call都引用了各自的绑定资源同一张纹理被多个action绑定循环内直接导出自然重复。解决不要再action循环里做导出改为先GetTextures()拿到资源全集再按资源的ResourceId去重后导出。如果目标本来就是“导出某几个pass用到的纹理”也要用一个set先收集ResourceId再统一走导出循环。这个坑的根源是“资源”和“资源绑定实例”不是一回事前者是集合后者是引用。5.5 V1.x小版本API漂移AttributeError和签名变化现象脚本在A机器上正常拿到B机器上跑报AttributeErrormodule renderdoc has no attribute TextureSaveDestination或者SaveTexture调用报参数个数不对。原因RenderDoc V1.x不同小版本的Python接口有过调整TextureSaveDest枚举名、SaveTexture签名都有变化直接从网上复制的脚本很难跨版本通用。解决脚本开头做一个自适应层。用一个helper函数统一封装TextureSave的创建和保存调用内部用getattr做兜底def make_texture_save(): if hasattr(rd, TextureSave): return rd.TextureSave() # 某些旧版本里的保存参数结构不同这里做兜底 return rd.TextureSave() def save_texture(controller, resource_id, out_path, opts): try: return controller.SaveTexture(resource_id, out_path, opts) except TypeError: # 旧版本签名SaveTexture(resource_id, opts) return controller.SaveTexture(resource_id, opts)写完之后在目标机器上跑一条导出观察日志确认走的是哪条分支不要裸调官方文档API。6. 让批量导出融入日常流程的一个验证技巧6.1 用像素统计把“导错了”变成“可检查”批量导出之后最怕的是文件数量对了、文件也能打开但内容不对。肉眼一张张看几十张图看到第三张就开始走神。我习惯在导出完跑一个像素统计脚本把每张PNG的均值、最大透明值、颜色通道比例打印出来。数值异常的纹理一眼就能看出来比如法线纹理的蓝色通道均值通常接近0.5如果统计出来是0.98说明通道顺序错了。from PIL import Image import numpy as np def analyze_png(path: str): img Image.open(path).convert(RGBA) arr np.asarray(img, dtypenp.float32) # 输出RGB均值与Alpha极值用于快速判断通道异常 rgb_mean arr[..., :3].mean(axis(0, 1)) alpha_max arr[..., 3].max() print(f{path} RGB均值: {rgb_mean.round(3)} Alpha最大: {alpha_max})跑一遍分析输出的数值是否合理比肉眼扫描靠谱得多。RGB均值里R、G、B三者比例异常往往就是通道顺序翻车或者格式转换出了问题。Alpha最大值为0的纹理如果它本该是半透明贴图就得回头查导出设置。6.2 用帧间diff做回归验证批量导出的另一个高频用途是回归改了一个渲染参数把修改前后的两帧分别导出纹理然后做diff确认只有预期的纹理变化其他纹理像素不应该有丝毫差异。全图逐一对比是体力活但像素diff只要几行def compare_frames(png_a: str, png_b: str) - float: img_a np.asarray(Image.open(png_a).convert(RGBA), dtypenp.float32) img_b np.asarray(Image.open(png_b).convert(RGBA), dtypenp.float32) if img_a.shape ! img_b.shape: return -1.0 # 尺寸不一致直接标记为异常 diff np.abs(img_a - img_b) return diff.mean() # 平均差异0.0表示完全一致平均差异为0基本可以判定两张图完全一致大于0就打印出对应的纹理名和diff值。把48张纹理的diff结果按数值排序先处理差异大的差异为0的直接跳过这个习惯帮我省了大量核对时间。我现在每调完一个渲染参数都会顺手跑一次批量导出加diff确认没有改坏相邻效果。这套流程用了很久出问题的次数明显少了希望帮到你。本文还有配套的精品资源点击获取 RenderDoc批量导出纹理：Python脚本自动化渲染调试
简介RenderDocV1.x批量导出纹理版是基于RenderDoc二次开发的图形调试增强工具面向游戏研发、图形编程及渲染分析人员解决原生版本只能逐个导出纹理、流程繁琐、耗时明显的问题。修改版通过扩展RenderDoc接口、遍历帧内纹理资源并引入多线程与多种常见格式支持把大量纹理的导出工作压缩为批量操作尤其适合贴图量大或需要周期性做资源审计的项目。压缩包共51个文件约51.6MB核心由29个dll动态库、6个exe执行程序、6个pyd扩展模块组成同时带有多份头文件与json配置并内置Qt/Python运行组件和x86/x64两套Release版本。包内同时提供图形界面与命令行可执行程序解压后可按环境选用直接用于帧纹理的批量提取和保存。已有1186人学习下载适合需要快速获取帧纹理、整理贴图资源或排查渲染问题的开发者收藏参考。1. 批量导出纹理这回事先把场景说清楚做帧调试的人都有这种经历RenderDoc V1.x里打开一个捕获场景里二三十张纹理等着逐个过目。右键一张张Export点到后面手酸还经常漏点。RenderDoc V1.x批量导出纹理版解决的就是这个写一段脚本把捕获里所有纹理按你定的命名规则、格式和层级一次性落到磁盘。这套做法适合三种人一是做渲染调试时要把帧里所有资源归档的开发者二是技术美术需要把美术资源在实时渲染里的终版效果导出来核对三是做自动化比对的人想拿不同帧的纹理做像素级diff。前提是你对RenderDoc的基本操作已经顺手但不想继续忍受机械重复。目标是让脚本帮你把“看完一张导出一次”变成“跑一条命令全部拿到”。2. 导出前必须搞清的三个概念资源、纹理与保存格式批量导出脚本的核心逻辑是“遍历描述 → 选格式 → 落盘”。如果不知道RenderDoc用什么结构描述一张纹理参数就只能靠猜导出的结果就会各种不对劲。这章先讲概念再给选型。2.1 RenderDoc眼里的纹理不只是一张图片在RenderDoc的回放环境里每个纹理资源对应一个唯一的ResourceId同时附带一份TextureDescription结构体。脚本里调用GetTextures()返回的就是这些描述对象的列表。字段大概包括width、height、depth是基础尺寸mips是mip层级数arraySize是数组层数type区分Texture1D、Texture2D、Texture2DArray、Texture3D、Cubeformat是ResourceFormat里面有compTypeFloat、UNorm、UInt、Depth等和compCount。批量导出最容易漏掉的就是arraySize和mips。UI右键导出时RenderDoc默认帮你导了“当前看得见的那一层”脚本没有这个默认值。你不处理CubeMap只拿到第一个面数组纹理只拿到第一层。这也是后面避坑章节的伏笔。format字段决定了你用什么格式落盘。比如format是BC7的压缩纹理RenderDoc在导出PNG时会自动解压如果你走原始数据读取再自己编码就得先解压BC7块这活儿自己做起来相当痛苦。所以脚本导出时尽量别自己碰原始字节交给RenderDoc的保存接口。2.2 三种导出姿势UI右键、离线脚本、内嵌控制台常见的导出姿势有三种。UI右键导出适合临时看一两张它把当前资源通道、当前mip、当前面的那一份存下来优点是直观缺点是没法批量。renderdoccmd是RenderDoc自带命令行工具可以回放捕获但它的职责更多在捕获、回放和自动化测试拿来做灵活导出不如脚本顺手。最可控的是Python接口能拿到完整描述、能做过滤、能循环、能重试出了错还能打日志。方式适用场景批量能力可定制性UI右键导出临时看一两张纹理弱低renderdoccmd捕获、回放、回归测试中中Python脚本批量导出、归档、像素比对强高我一般会直接用Python接口。RenderDoc安装目录里自带Python接口模块够用脚本跑在哪个环境不重要重要的是先把接口跑通。V1.x的接口整体稳定但小版本之间偶尔有枚举名和函数签名的漂移遇到问题先查本机版本的接口签名别上来就怀疑逻辑。2.3 导出格式怎么选PNG、DDS、KTX、EXR脚本里最难定的不是逻辑是格式。批量导出前先想清楚这批纹理给谁看。导出一份用于核对的纹理我习惯PNG导出给引擎侧用的DDS或KTX发现纹理里存了float数据比如GBuffer里的深度/法线用EXR才能保证不丢精度。格式典型场景是否保留mip备注PNG文档、验收、像素比对否无损适合RGBA8DDS回拷引擎、工具链是能保留压缩块信息KTX移动端、运行时加载是需要配套解析库EXRHDR、float纹理否保存高动态范围TextureSave里通过format字段指定目标格式比如FileType.PNG、FileType.DDS、FileType.KTX、FileType.EXR。不同格式会直接影响保存接口内部走的编码路径所以“先定格式再写循环”是对的。另外还要理解TextureSave这个配置对象它管的不只是格式还有mip、slice、目的位置磁盘还是内存缓冲。批量脚本里常用的是把destination设为Disk直接落盘。3. 用Python脚本把批量导出跑通最小可用版现在开始动手。这章给一个能直接用的最小脚本然后拆开讲参数含义。跑通之后再做命名、过滤和重试这些工程化的事。3.1 最小脚本遍历纹理、逐个落盘import renderdoc as rd import os def export_all_textures(capture_path: str, output_dir: str) - int: # 初始化RenderDoc运行时 rd.Initialise() # 打开捕获文件并加载 controller rd.ReplayController.OpenCaptureFile(capture_path) if controller is None: raise RuntimeError(无法打开捕获文件: %s % capture_path) err controller.LoadCapture() if err ! 0: raise RuntimeError(加载捕获失败错误码: %d % err) # 遍历所有纹理资源 textures controller.GetTextures() os.makedirs(output_dir, exist_okTrue) for tex in textures: # tex 是 TextureDescriptionresourceId 唯一标识资源 out_path os.path.join(output_dir, f{tex.resourceId}.png) result controller.SaveTexture(tex.resourceId, out_path) print(f{tex.resourceId} {tex.width}x{tex.height} - {out_path} ({result})) controller.Shutdown() rd.Shutdown() return 0 if __name__ __main__: export_all_textures(frame_0123.rdc, exported_textures)这个脚本的逻辑很直白初始化RenderDoc打开捕获文件加载回放拿全部纹理描述循环保存成PNG。SaveTexture第一个参数是ResourceId第二个参数是落盘路径。这里没有指定mip和slice默认保存的是“可用视图”对应的那一层对于普通Texture2D够用了。脚本末尾的Shutdown不能省批量跑多个捕获文件时不释放回放控制器会累积显存和内存。跑之前有两件事要确认一是确保Python能找到renderdoc模块常见做法是在RenderDoc安装目录里找到Python接口模块路径或者直接用RenderDoc UI自带的内嵌控制台跑省掉sys.path的折腾二是确认捕获文件是用匹配的V1.x版本生成的版本跨太大的文件打不开或者加载报错。3.2 参数怎么调整mip层、数组切片、目标目录最小脚本导出的是“默认层”但真实场景里你得控制导出哪一层mip、哪一层数组切片、命名带什么后缀。这就需要TextureSave对象def export_with_options(controller, tex, output_dir): # 构造保存选项 opts rd.TextureSave() opts.format rd.FileType.PNG opts.mip 0 # 只导出第0层mip opts.slice 0 # 数组/立方体贴图的第0层 opts.destination rd.TextureSaveDestination.Disk out_path os.path.join(output_dir, f{tex.resourceId}_m0.png) # 带选项的保存不同小版本对tex参数的传法略有差异 controller.SaveTexture(tex.resourceId, out_path, opts)mip参数控制mip层级0是最高分辨率那一层tex.mips - 1是最小的一层。slice参数在普通Texture2D上无效但在Texture2DArray和Cube上就是决定生死的关键。Cube纹理的arraySize通常是6每个面一个slice遍历时要把slice从0循环到5才能导出完整天空盒。destination设为Disk表示直接写文件如果后续要对纹理数据做二次处理可以改成MemoryBuffer从返回的字节数组自己处理。这里要特别提一下SaveTexture在不同小版本里的签名差异。V1.x早期版本有的要求传(resourceId, path)有的版本传(resourceId, path, opts)还有的版本把path放进了opts.destination。写通用脚本时用hasattr或者try/except包一层别把签名写死。用dir(controller.SaveTexture)看本机版本的签名比翻文档快。3.3 从UI里验证脚本结果和手点导出一致脚本跑完先别急着批量使用选一张纹理做一致性校验。在RenderDoc UI里找到同一个ResourceId的纹理右键Export成PNG然后用文件比对工具对比UI导出文件和脚本导出文件。理论上同一版本、同一导出格式、同一mip和slice两份文件的像素数据应该完全一致。我习惯用md5做快速校验md5sum ui_export.png script_export.png。如果md5一致说明脚本走的路子和UI一致可以信任批量结果如果不一致先检查导出的mip和slice是否一致再看是不是文件名里带了不同的后缀。UI右键导出时RenderDoc也遵循同样的TextureSave逻辑出现不一致大概率是你脚本里设置了UI没有的设置项比如mip不是0。4. 把脚本改成能每天用的工具命名、过滤和错误处理最小脚本能跑通但要天天用还差得远。原始文件名是resourceId数字串看不出哪张是哪张捕获里还混着一堆1x1像素的占位纹理和buffer导出来纯属噪音。这章把脚本往工具方向推。4.1 命名规则加尺寸、格式、层级别用resourceId裸奔resourceId做文件名有一个好处是唯一但可读性为零。你在项目里看到一个1234567890.png根本不知道它对应的是漫反射还是法线。我常用的命名规则是把纹理名、尺寸、格式和层级拼在一起def build_name(tex, mip_idx0, slice_idx0): fmt_name tex.format.shortName() if hasattr(tex.format, shortName) else str(tex.format) base tex.name if tex.name else str(tex.resourceId) return f{base}_{tex.width}x{tex.height}_{fmt_name}_m{mip_idx}_s{slice_idx}.png纹理的name字段在捕获里不一定有很多内部资源名是空的。这时用resourceId兜底至少保证不重名。shortName方法把R8G8B8A8_UNORM压缩成可读性好的短名比打一串全称好。带上mip和slice后缀是为了避免同一纹理不同层导出时互相覆盖。最后清理文件名里的非法字符把空格换成下划线去掉路径分隔符否则在部分平台上写文件会报错。4.2 过滤逻辑只导关心的事件期间的纹理一帧捕获里的纹理资源数量比你想的多。RenderDoc的GetTextures()返回所有分配过的纹理包括1x1的占位纹理、深度缓冲、staging纹理。你真正关心的可能是几张主场景纹理所以过滤逻辑要加for tex in textures: # 跳过buffer类型 if tex.type rd.TextureType.Buffer: continue # 跳过过小的纹理 if tex.width 16 and tex.height 16: continue # 跳过明显是占位符的无名资源 if not tex.name and tex.width 4: continue # 导出 opts rd.TextureSave() opts.format rd.FileType.PNG opts.mip 0 opts.slice 0 opts.destination rd.TextureSaveDestination.Disk out_path os.path.join(output_dir, build_name(tex)) controller.SaveTexture(tex.resourceId, out_path, opts)过滤条件按需增减。比如调试GBuffer时反而要导深度纹理这时就别按维度过滤而是按compType过滤把Depth类型单独挑出来导EXR。常见做法是先跑一次全量导出py文件里打印每个纹理的name、type、format、尺寸看一遍再定过滤规则。第一次别太自信先看全貌再砍数据。4.3 断点续导与失败重试批量导出几十张纹理时中途可能因为磁盘空间不足、单个纹理过大、驱动超时等问题中断。重新从头跑一遍浪费时间所以断点续导是刚需。我通常维护一个文本清单记录已完成导出的文件路径manifest_path os.path.join(output_dir, exported.txt) done set() if os.path.exists(manifest_path): with open(manifest_path, r, encodingutf-8) as fp: done.update(line.strip() for line in fp if line.strip()) for tex in textures: out_path os.path.join(output_dir, build_name(tex)) if out_path in done: continue for attempt in range(2): try: controller.SaveTexture(tex.resourceId, out_path, opts) with open(manifest_path, a, encodingutf-8) as fp: fp.write(out_path \n) break except Exception as e: print(f第{attempt 1}次导出失败: {tex.resourceId} - {e})这个做法的关键是“先写清单再继续下一个”确保导出成功的文件一定被记录。失败重试两次就放弃避免死循环。清单文件本身也方便你事后统计哪些纹理成功、哪些失败、失败原因是什么。配合上一条的打印日志基本能定位所有问题。5. 批量导出纹理避坑实录现象、原因与解决脚本跑多了总会遇到玄学问题。这章写五个我实际踩过的坑按“现象 → 原因 → 解决”记录给后来者少烧点时间。5.1 黑图翻车压缩纹理没有正确解压就落盘现象导出的PNG完全黑或者大面积花屏但RenderDoc UI里预览却正常。第一次遇到以为是显存损坏吓一跳。原因部分纹理在驱动侧是块压缩格式BC1/BC3/BC7RenderDoc的预览视图会做解压显示但脚本直接读取原始数据时拿到的是压缩块。后续保存为PNG时如果代码路径里没有触发解压就会把压缩数据当像素数据编码得到黑图和花屏。解决把导出交给SaveTexture并明确指定目标格式。RenderDoc在保存为PNG/DDS/EXR时会按目标格式自动处理源纹理的压缩状态。千万不要自己用GetTextureData拿字节缓存再交给PIL之类的库编码除非你明确知道自己在解压BC块。另外导出时留意tex.format.blockSize字段看到blockSize大于0的格式优先用SaveTexture而不是手写编码路径。5.2 数组纹理和CubeMap只导出第一层现象CubeMap纹理导出的PNG只有第一个面的内容另外五个面凭空消失数组纹理导出的结果只有slice 0。原因SaveTexture默认的slice参数是0UI右键导出时会自动按当前选中的面处理脚本没有这个默认必须显式循环。解决判断tex.arraySize或tex.type。Cube类型的arraySize在RenderDoc里通常表现为6写循环时不要用arraySize硬编码按type判断更稳妥if tex.type rd.TextureType.Cube: slice_count 6 elif tex.type rd.TextureType.Texture2DArray: slice_count tex.arraySize else: slice_count 1 for slice_idx in range(slice_count): opts.slice slice_idx out_path ... # 带slice后缀 controller.SaveTexture(tex.resourceId, out_path, opts)5.3 Windows下中文路径导出0字节现象脚本没报错输出目录也生成了文件但文件大小是0。单独查文件名发现路径里带中文或者空格比如D:\测试输出\water map.png。原因V1.x部分版本的底层文件写入用了窄字符路径在Windows上遇到非ASCII字符时写文件失败但上层接口没有把错误透传出来静默产出0字节文件。解决全ASCII输出目录文件名里不要留中文。路径中的空格尽量换成下划线。这是一个干脆的规避方案——为验证工具折腾宽字符路径编码不值得。同时加一道防线保存后立即检查文件大小等于0就视为导出失败打印警告并计入失败清单。这样即使遇到其他路径编码问题也不会静默通过。5.4 在action循环里到处调SaveTexture导致重复导出几十次现象导出的文件数量比预期多一个数量级同一张纹理出现几十次只是名字后缀不同。原因遍历渲染动作列表action tree时每个draw call都引用了各自的绑定资源同一张纹理被多个action绑定循环内直接导出自然重复。解决不要再action循环里做导出改为先GetTextures()拿到资源全集再按资源的ResourceId去重后导出。如果目标本来就是“导出某几个pass用到的纹理”也要用一个set先收集ResourceId再统一走导出循环。这个坑的根源是“资源”和“资源绑定实例”不是一回事前者是集合后者是引用。5.5 V1.x小版本API漂移AttributeError和签名变化现象脚本在A机器上正常拿到B机器上跑报AttributeErrormodule renderdoc has no attribute TextureSaveDestination或者SaveTexture调用报参数个数不对。原因RenderDoc V1.x不同小版本的Python接口有过调整TextureSaveDest枚举名、SaveTexture签名都有变化直接从网上复制的脚本很难跨版本通用。解决脚本开头做一个自适应层。用一个helper函数统一封装TextureSave的创建和保存调用内部用getattr做兜底def make_texture_save(): if hasattr(rd, TextureSave): return rd.TextureSave() # 某些旧版本里的保存参数结构不同这里做兜底 return rd.TextureSave() def save_texture(controller, resource_id, out_path, opts): try: return controller.SaveTexture(resource_id, out_path, opts) except TypeError: # 旧版本签名SaveTexture(resource_id, opts) return controller.SaveTexture(resource_id, opts)写完之后在目标机器上跑一条导出观察日志确认走的是哪条分支不要裸调官方文档API。6. 让批量导出融入日常流程的一个验证技巧6.1 用像素统计把“导错了”变成“可检查”批量导出之后最怕的是文件数量对了、文件也能打开但内容不对。肉眼一张张看几十张图看到第三张就开始走神。我习惯在导出完跑一个像素统计脚本把每张PNG的均值、最大透明值、颜色通道比例打印出来。数值异常的纹理一眼就能看出来比如法线纹理的蓝色通道均值通常接近0.5如果统计出来是0.98说明通道顺序错了。from PIL import Image import numpy as np def analyze_png(path: str): img Image.open(path).convert(RGBA) arr np.asarray(img, dtypenp.float32) # 输出RGB均值与Alpha极值用于快速判断通道异常 rgb_mean arr[..., :3].mean(axis(0, 1)) alpha_max arr[..., 3].max() print(f{path} RGB均值: {rgb_mean.round(3)} Alpha最大: {alpha_max})跑一遍分析输出的数值是否合理比肉眼扫描靠谱得多。RGB均值里R、G、B三者比例异常往往就是通道顺序翻车或者格式转换出了问题。Alpha最大值为0的纹理如果它本该是半透明贴图就得回头查导出设置。6.2 用帧间diff做回归验证批量导出的另一个高频用途是回归改了一个渲染参数把修改前后的两帧分别导出纹理然后做diff确认只有预期的纹理变化其他纹理像素不应该有丝毫差异。全图逐一对比是体力活但像素diff只要几行def compare_frames(png_a: str, png_b: str) - float: img_a np.asarray(Image.open(png_a).convert(RGBA), dtypenp.float32) img_b np.asarray(Image.open(png_b).convert(RGBA), dtypenp.float32) if img_a.shape ! img_b.shape: return -1.0 # 尺寸不一致直接标记为异常 diff np.abs(img_a - img_b) return diff.mean() # 平均差异0.0表示完全一致平均差异为0基本可以判定两张图完全一致大于0就打印出对应的纹理名和diff值。把48张纹理的diff结果按数值排序先处理差异大的差异为0的直接跳过这个习惯帮我省了大量核对时间。我现在每调完一个渲染参数都会顺手跑一次批量导出加diff确认没有改坏相邻效果。这套流程用了很久出问题的次数明显少了希望帮到你。本文还有配套的精品资源点击获取