简介针对复杂透明场景中物体绘制顺序导致的颜色错乱问题这份基于链表的OIT无序透明实现为OpenGL开发者提供了一套不依赖绘制顺序即可正确渲染的参考方案适合烟雾、火光、玻璃、毛发等半透明效果开发也可作为计算机图形学课程或进阶学习的示例代码。压缩包共458个文件总大小846KB核心代码以hpp、inl、h等头文件形式呈现同时包含vert/frag着色器、少量cpp入口程序及png效果截图目录结构清晰便于按链表节点管理、深度测试配置、像素颜色累加等功能模块检索。资源内提供可运行的着色器与示例程序能够演示多层透明物体重叠、阴影投射以及光线在透明介质中的折射反射效果还针对链表长度限制和近似计算给出性能优化思路帮助读者平衡真实感与渲染开销理解从原理到工程落地的完整过程。目前已有137人学习下载适合掌握OpenGL基础并希望深入OIT技术的图形学开发者。1. 透明渲染的顺序问题为什么值得花一篇笔记讲半透明物体在渲染管线里一直是靠“从远到近逐个混合”来糊弄的。场景里一旦出现两片交叉玻璃或者粒子互相穿过物体级排序就不再成立相机一转动穿帮和闪烁立刻暴露。OpenGL 基于链表的 OIT 把同一个像素覆盖到的所有透明片段挂到一条 GPU 链表中第二遍再按深度排序、逐像素合成从原理上摆脱了物体绘制顺序的约束。它适合粒子系统、烟雾、毛发、车窗玻璃这类大量半透明物件互相交叠的场景。做这套方案需要 OpenGL 4.3 以上的驱动和 GLSL 的基本功下面把一个可复现的两遍 Pass 实现拆开讲。2. 混合公式推到极限排序必须落到像素上2.1 一张半透明面的合成是递归的透明度混合的标准公式是C α_s · C_s (1 - α_s) · C_d当两个半透明面片 A、B 先后覆盖同一个像素时最终颜色是“后画的叠在先画的上面”。先画 A 再画 B和先画 B 再画 A结果是不同的。这是 alpha 混合的基本特性混合操作不满足交换律。到三层、四层叠加时这个递归关系会变得非常明显。一个半透明红色玻璃挡住蓝色玻璃红在前还是蓝在前人眼能一眼分辨。渲染器必须知道每个像素位置上所有透明片段的准确深度顺序然后从最远到最近逐个执行 over 操作才能得到和现实一致的结果。问题在于“物体级排序”根本做不到这一点。两片交叉的玻璃板在屏幕左侧是 A 在前在屏幕右侧可能变成 B 在前。用单个物体深度值排序只能取一个代表值必然导致部分像素顺序错误。粒子系统更不用提几千个粒子互相穿插任何一个粒子对其他粒子的遮蔽关系都随视角不断变化物体级排序在数学上就不成立。所以结论很直接透明排序必须发生在像素级也就是对每个像素收集所有被覆盖到的透明片段再按深度排序。这个“像素内的片段列表”从哪来最容易落地的数据结构就是链表。2.2 链表OIT的两遍Pass架构基于链表的 OIT 把工作拆成两遍。第一遍渲染所有透明几何体但这一遍不执行混合只把每个片段的颜色、深度、下一个节点索引写进一块 GPU 内存池同时用原子操作把这个新节点插入到“以屏幕像素坐标为下标”的链表头。这样每个像素就有了一个只属于它的透明片段链表节点数等于该像素被覆盖的层数。第二遍渲染一个全屏四边形对每个像素从链表头开始遍历把颜色和深度收集到局部数组里按深度排序最后从不透明背景开始从远到近依次执行 alpha 混合。这遍结束后的颜色就是正确的 OIT 结果。用到的三块 GPU 资源需要先说清楚链表头用一张GL_R32UI纹理每个像素存一个 uint表示该像素链表的第一个节点索引空链表的哨兵值是0xFFFFFFFF节点池用一块 SSBO保存结构体数组{ color, depth, next }节点分配器用 OpenGL 的 atomic counter每帧从 0 开始递增返回的旧值就是新节点索引。容易有人把链表头和节点池搞混。链表头只是入口地址真正数据在 SSBO 的节点数组里。每个新片段写入时imageAtomicExchange把旧链表头换成新节点索引并把旧链表头写进新节点的next字段。新节点永远插在链表最前面所以链表顺序是“后写入在前”这没关系第二遍排序时会把它重排。2.3 为什么不用深度剥离也不用加权平均深度剥离的原理是每剥离一层就重新渲染一遍场景。需要的层数越多Pass 数越多。一个粒子密集的场景某些像素可能覆盖十几层深度剥离要跑十几遍渲染开销直接翻十几倍。而且剥离结束后如果还想补漏得做双向深度剥离或者多层剥离工程复杂度和显存开销都不可控。链表 OIT 用一次 Pass 就把全部层收集完成本只和总节点数相关。加权平均 OIT 是另一种思路不排序把颜色和覆盖率累加到一个缓冲里最后一次性混合。这个方案对体积烟、雾这类本身没有清晰边界的材质效果不错但遇到高光、硬边、交错半透明面板时会产生明显错误因为它丢失了层与层之间的遮挡关系。链表 OIT 属于精确 OIT能处理任意重叠顺序是当前桌面端渲染引擎做粒子、毛发、复杂半透明场景时最常用的基准方案。它也不是没有代价显存占用和原子操作的开销是主要限制后续章节会逐一处理。3. 用OpenGL写两遍Pass节点写入与逐像素合成3.1 三块缓冲链表头纹理、节点池SSBO、原子计数器先明确资源布局。假设画面尺寸是W x H链表头纹理是一张宽W高H的GL_R32UI纹理不生成 mipmap每个像素存放该链表第一个节点的索引初始全部填充0xFFFFFFFF。节点池是 SSBO元素类型是 GLSL 结构体FragmentNode容量在初始化时固定通常按“像素总数 x 平均层数”估算。资源类型用途链表头纹理GL_TEXTURE_2D/GL_R32UI每个像素存链表入口索引哨兵为0xFFFFFFFF节点池SSBO /std430存所有透明片段的颜色、深度、next 指针节点计数器atomic counter buffer每帧从 0 递增分配新节点索引GLSL 结构体定义如下Pass 1 和 Pass 2 的 shader 里都要有这份声明struct FragmentNode { vec4 color; // 非预乘 RGBA float depth; // gl_FragCoord.z范围 [0,1] uint next; // 下一个节点索引0xFFFFFFFF 表示结束 };这里有一个容易被忽略的布局问题。std430布局下vec4按 16 字节对齐所以depth偏移量是 16next偏移量是 20整个结构体对齐后占用 32 字节。一个节点 32 字节1080p 场景如果平均覆盖 4 层光节点池就要 8M x 32B也就是 256MB 显存。后面第 4 章会给出紧凑存储版本把单节点压到 16 字节。第一版实现建议直接按 32 字节写逻辑清楚调试成本低。3.2 Pass 1把透明片段挂进链表Pass 1 的 fragment shader 核心逻辑是分配节点、写入数据、插入链表头代码很短但每一步都是关键#version 450 core struct FragmentNode { vec4 color; float depth; uint next; }; layout(binding 0, r32ui) uniform uimage2D headPointerImg; layout(binding 0, offset 0) uniform atomic_uint nodeCounter; layout(std430, binding 1) buffer NodePool { FragmentNode nodes[]; }; layout(location 0) in vec4 vColor; layout(location 0) out vec4 unusedColor; uniform uint maxNodeCount; void main() { // 从原子计数器取一个节点索引返回的是递增前的旧值 uint idx atomicCounterIncrement(nodeCounter); // 池满了就丢弃注意计数器已经递增这个索引被浪费 if (idx maxNodeCount) { discard; } // 把链表头换成当前节点返回旧链表头作为 next uint oldHead imageAtomicExchange(headPointerImg, ivec2(gl_FragCoord.xy), idx); // 写入节点数据顺序无关 nodes[idx].color vColor; nodes[idx].depth gl_FragCoord.z; nodes[idx].next oldHead; }逻辑分三步。第一步atomicCounterIncrement从计数器 buffer 里拿到一个全局唯一索引这个调用是原子的多个像素同时执行也不会取到同一个值。第二步imageAtomicExchange对链表头纹理执行原子交换把新节点索引写进去同时返回之前存着的旧链表头。第三步把颜色、深度、旧链表头写进 SSBO 节点池。有一个细节必须理解discard发生时计数器已经递增了也就是说这个索引被白白浪费掉。池满之后继续丢弃是合理的但计数器会继续增长。如果你把maxNodeCount同时用来判断池是否满了这个问题不大但不能用计数器当前值当作已经分配的节点数做统计它会偏大。真正做内存诊断时要单独维护一个统计计数器。maxNodeCount这个 uniform 由 CPU 侧传入等于 SSBO 里节点数组的长度。shader 端无法直接查询 SSBO 大小所以必须显式传入。另一个常见做法是把最大节点数写进 shader 的#define但这样每改一次节点池大小都要重编 shader工程上不推荐。3.3 Pass 2遍历链表、排序、逐像素合成Pass 2 不再渲染几何体而是渲染一个全屏三角形对每个像素做“收集-排序-合成”三步#version 450 core struct FragmentNode { vec4 color; float depth; uint next; }; layout(binding 0, r32ui) uniform uimage2D headPointerImg; layout(std430, binding 1) buffer NodePool { FragmentNode nodes[]; }; uniform sampler2D opaqueScene; layout(location 0) out vec4 fragColor; // 每个像素最多参与合成的透明片段数超出部分被截断 #define MAX_PIXEL_NODES 16 void main() { ivec2 p ivec2(gl_FragCoord.xy); // 1. 从链表头开始收集节点链表长度超限则截断 uint idx texelFetch(headPointerImg, p, 0).x; vec4 col[MAX_PIXEL_NODES]; float dep[MAX_PIXEL_NODES]; int n 0; while (idx ! 0xFFFFFFFFu n MAX_PIXEL_NODES) { col[n] nodes[idx].color; dep[n] nodes[idx].depth; idx nodes[idx].next; n; } // 2. 按深度升序排序简单冒泡足够因为 n 通常很小 for (int i 0; i n - 1; i) { for (int j i 1; j n; j) { if (dep[j] dep[i]) { float td dep[i]; dep[i] dep[j]; dep[j] td; vec4 tc col[i]; col[i] col[j]; col[j] tc; } } } // 3. 从不透明背景开始从远到近执行 over 混合 vec2 uv p / vec2(textureSize(opaqueScene, 0)); vec3 bg texture(opaqueScene, uv).rgb; for (int i n - 1; i 0; --i) { // mix(dst, src, a) 等价于 dst*(1-a) src*a bg mix(bg, col[i].rgb, col[i].a); } fragColor vec4(bg, 1.0); }第一步用的是texelFetch而不是texture因为链表头是整型纹理不需要过滤采样也不需要在片元坐标处做归一化采样。texelFetch直接按整数像素坐标读取干净利落。收集时局部数组大小必须是编译期常量所以MAX_PIXEL_NODES用宏定义。链表超过这个上限会被截断这是为保证 shader 不会因为动态数组长度导致性能崩溃。第二步排序用的是最朴素的冒泡排序。每个像素平均只有几层透明片段冒泡排序的复杂度完全可接受。这里有一个隐患冒泡排序不是稳定排序两个深度完全相同的节点它们的相对顺序可能每次运行都不同。视觉表现为共面几何体闪烁。第 5 章会专门讲怎么处理。第三步合成是从远到近。mix(bg, col[i].rgb, col[i].a)已经把 alpha 因子放进去了前提是颜色值是非预乘 RGBA。如果你的粒子 shader 输出的是预乘颜色这里必须改成累加方式否则边缘会变暗。这个约定要在整个渲染管线里保持一致。3.4 CPU侧初始化与每帧状态设置OpenGL 侧的准备工作分三块创建纹理与 SSBO、每帧重置链表头和计数器、设置 Pass 1 和 Pass 2 的渲染状态。核心代码片段如下// 每帧开始链表头全部重置为哨兵值 const GLuint sentinel 0xFFFFFFFFu; glClearTexSubImage(headTex, 0, 0, 0, 0, W, H, 1, GL_RED_INTEGER, GL_UNSIGNED_INT, sentinel); // 原子计数器清零 GLuint zero 0; glBindBuffer(GL_ATOMIC_COUNTER_BUFFER, counterBuf); glBufferSubData(GL_ATOMIC_COUNTER_BUFFER, 0, sizeof(zero), zero); glBindBufferBase(GL_ATOMIC_COUNTER_BUFFER, 0, counterBuf); // Pass 1透明物体写入链表 glDisable(GL_BLEND); glEnable(GL_DEPTH_TEST); glDepthMask(GL_FALSE); glBindImageTexture(0, headTex, 0, GL_FALSE, 0, GL_READ_WRITE, GL_R32UI); glUseProgram(pass1Prog); DrawTransparentObjects(); // Pass 2全屏合成 glDisable(GL_DEPTH_TEST); glUseProgram(pass2Prog); DrawFullscreenTriangle(); // 调试用读回当前帧使用了多少节点 GLuint usedNodes 0; glGetBufferSubData(GL_ATOMIC_COUNTER_BUFFER, 0, 4, usedNodes);glClearTexSubImage只清一层不需要给链表头生成 mipmap所以 level 填 0。很多翻车现场就出在这里链表头纹理没清上一帧的索引残留这帧遍历时就走到了一条死链最终显示黑块或花屏。Pass 1 里glDepthMask(GL_FALSE)必须执行否则半透明物体会把不透明场景的深度缓冲洗掉。另一个关键点是glDisable(GL_BLEND)这一遍不混合只记录混合是 Pass 2 做的事。如果你忘了关闭混合Pass 1 写进 SSBO 的颜色会被帧缓冲里已有的颜色污染但注意污染的不是 SSBO而是最终的隐藏缓冲。因为 Pass 2 全屏覆盖Pass 1 的颜色输出最终不会出现在屏幕上所以很多人会忽略这个状态。但你挂调试器看 Pass 1 的渲染目标时会一脸懵所以还是按规范关掉。glGetBufferSubData会在每一帧产生 CPU 和 GPU 的同步等待只能用来调优不能留在发布代码里。连续跑几十帧后收敛的频率和呈现的波峰数能直接指导你把节点池设置到多大。4. 工程参数节点池、颜色精度和深度缓冲的取舍4.1 节点池容量按平均层数估算再用实测校准节点池大小直接决定显存占用和正确性。太小会丢片段太大浪费显存。常见估算公式是节点数 屏幕像素数 × 平均每像素透明覆盖层数1080p 是 1920 x 1080约 207 万像素。如果平均覆盖 4 层节点数就是约 830 万。按第 3 章的 32 字节节点算约 265MB这个数字已经不小了。场景里如果粒子密集平均层数到 8容量直接翻倍到 500MB很多显卡吃不消。所以不能只靠拍脑袋设定。实际做法是先用一个保守偏大的值跑通然后每帧读回usedNodes做统计。连续统计 100 帧找最大值再乘以 1.3 到 1.5 的安全系数作为最终节点池大小。用第 3 章的glGetBufferSubData就够了但要注意同步开销只在调试窗口期启用。另一个工程技巧是加一个“溢出探测器”。在 Pass 2 里对每个像素的链表长度做atomicAdd计数把超过MAX_PIXEL_NODES的像素数量记录下来。再配合usedNodes你就能区分两种问题全局节点池不够还是单个像素链表过长。前者调大 SSBO后者调大MAX_PIXEL_NODES并且可能还要配合裁剪场景。4.2 紧凑节点存储把单节点从32字节压到16字节第 3 章的FragmentNode里vec4 color占 16 字节depth和next各占 4 字节最后对齐到 32 字节。一半是浪费的。如果颜色不需要 HDR 精度可以打包成uint一个节点正好 16 字节struct PackedFragmentNode { uint color; // RGBA8使用 packUnorm4x8 写入 uint depth; // 深度整数0x00000000 到 0xFFFFFFFF uint next; // 实际占用 12 字节std430 对齐到 16 字节 };Pass 1 写入时做两层转换nodes[idx].color packUnorm4x8(vColor); // vec4 - uint nodes[idx].depth uint(gl_FragCoord.z * float(0xFFFFFFFFu));Pass 2 读取时用unpackUnorm4x8还原颜色深度则直接用整数比较不需要转回浮点。整数深度有一个额外好处两个片段深度完全相同的情况可以用 “先比深度再比节点索引” 的方式做稳定排序避免共面闪烁。RGBA8 的代价是颜色量化误差。在渐变烟雾场景中层数多时能看到轻微色阶。如果你用RGBA16F渲染粒子pack 后精度就浪费了。这时候要么忍受 32 字节节点要么换一个 RGBA16F 的 packed 方案。工程上常见做法是主场景用 HDR透明粒子用 LDR 颜色因为粒子的高频细节本身会掩盖量化误差。4.3 深度缓冲配合透明物要测深度但不写深度Pass 1 渲染透明物体时必须复用不透明场景的深度缓冲。也就是说渲染顺序是渲染不透明几何体 - 写入深度缓冲和颜色缓冲 - Pass 1 透明物 - Pass 2 全屏合成Pass 1 开启GL_DEPTH_TEST关闭GL_DEPTH_WRITE。这样被墙壁挡住的车窗玻璃不会进入链表穿过墙的粒子片段也会在深度测试阶段被正确丢弃。有个暗坑值得讲清楚fragment shader 里写了imageAtomicExchange这种 image 操作后OpenGL 规范会强制关闭 early fragment test。也就是说深度测试从“片元着色器执行之前”被挪到“之后”每个被遮挡的透明片段都要完整跑一遍 shader 才会被丢掉。粒子越多这个浪费越明显。缓解方式是把深度的预判放到 shader 开头先用gl_FragCoord.z和场景深度纹理做一次手动判断如果不通过就直接丢弃。但注意discard不能放在原子操作之后不然计数器已经递增节点已经分配白白浪费一个索引。更合理的做法是用全局深度纹理提前采样float sceneDepth texelFetch(depthTex, ivec2(gl_FragCoord.xy), 0).r; if (gl_FragCoord.z sceneDepth) { discard; // 被不透明物体遮挡 }这段预判放在atomicCounterIncrement之前被遮挡的片段根本不会分配节点。虽然渲染管线的 early-z 无法自动启用但手动丢弃的效果是等价的。4.4 MSAA、后处理和半透明体的交互链表头纹理是单样本的没有 MSAA 版本。如果你的主场景是 4x MSAA透明物渲染到同一个 MSAA 帧缓冲是不行的因为全屏 Pass 2 会覆盖整个帧缓冲MSAA resolve 之后再做全屏合成会丢掉多层样本。常见做法是双缓冲不透明场景渲染到 MSAA 帧缓冲然后 resolve 到一张普通纹理透明物体连同链表头渲染到单样本帧缓冲Pass 2 在单样本帧缓冲上完成合成。这样 MSAA 效果只体现在不透明场景上透明物体边缘的锯齿需要另外处理但至少不会出现黑边或错误混合。opaqueScene纹理采样时不要开 mipmap。全屏三角形覆盖的 uv 范围是 0 到 1无 mipmap 的线性过滤足够。如果开了 mipmap 又没正确生成Pass 2 可能采样到半透明的 level合成背景会偏色。5. 避坑5个把链表OIT搞挂的典型现场5.1 现象透明物体全部消失只剩下不透明场景原因链表头纹理没有初始化成哨兵值默认是 0。因为节点索引从 0 开始0 恰好是第一个合法节点。如果链表头为 0Pass 2 读到的idx 0进入循环取出节点 0 的数据然后idx nodes[0].next如果next是 0就形成了自引用循环直接卡死或全部丢弃。解决链表头必须用0xFFFFFFFF作为哨兵每帧glClearTexSubImage写入这个值。如果你不想用全 F从 1 开始分配节点也可以0 留作哨兵但会浪费一个节点空间而且第 3 章的代码里if (idx maxNodeCount)的边界条件也要跟着改。推荐直接使用0xFFFFFFFFuOpenGL 的 uint 纹理天然支持这个值。5.2 现象两个重叠半透明平面反复闪烁排序结果不稳定原因深度值相等时第 3 章那个冒泡排序不稳定。两个玻璃板共面深度完全一样dep[j] dep[i]不成立顺序由链表插入顺序决定而链表插入顺序和渲染顺序相关所以每一帧可能不同。解决排序时加入节点索引作为次级比较键。节点索引是唯一的能模拟稳定排序// 记录每个收集节点的原始索引 uint nodeIdx[MAX_PIXEL_NODES]; // 收集循环里写 nodeIdx[n] idx; // 排序比较条件改为 if (dep[j] dep[i] || (dep[j] dep[i] nodeIdx[j] nodeIdx[i])) { // 交换 dep/col/nodeIdx }加上这个条件后同深度节点的相对顺序由索引大小决定而索引是原子分配时确定的绝不重复也就不会出现像素间的随机性。另一种做法是在深度值加一个像素级微扰但会影响真实遮挡关系不推荐。5.3 现象粒子密度高时近处颜色变淡或偏色现象靠近一团烟雾的时候烟雾反而变透明了或者颜色发灰。原因MAX_PIXEL_NODES太小链表在循环收集阶段被截断。注意截断发生在链表头部而链表头部存的是“最新写入”的节点不是你直觉中的“最近”节点。结果就是靠近相机的那几层片段可能恰好被丢弃合成颜色就不正确。解决优先调大MAX_PIXEL_NODES从 16 往上试到 32 或 64观察显存和性能变化。开局内存池的 SSBOmaxNodeCount也要变大只调MAX_PIXEL_NODES没用节点池如果不够Pass 1 直接丢弃还是缺层。这类问题不能靠猜。第 4 章里的溢出计数器就是为它准备的如果每个像素的溢出计数持续大于 0说明MAX_PIXEL_NODES不够如果全局usedNodes接近maxNodeCount说明节点池不够。两个方向分开调不要一起拍脑袋。5.4 现象帧率骤降粒子耗尽了显卡的算力现象透明物体少的时候帧率正常粒子一满屏帧率从 60 掉到 20 以下。原因Pass 1 的原子竞争是主要瓶颈。上万个粒子同时执行atomicCounterIncrement和imageAtomicExchange即使分散到多个像素同一像素上的多个片段依然串行执行原子操作。另一个瓶颈是 Pass 2 的冒泡排序每个像素 16 层时冒泡要做 120 次比较虽然不多但全屏两百万像素累计起来很可观。解决先限制场景里透明几何体的总量这是“最有效但最土”的做法。工程上可以做的优化包括按距离裁剪粒子、把远处粒子切换到加权平均 OIT 的低精度版本、在 Pass 2 阶段把节点的局部数组按层数n做 switch 展开消除循环分支。分享一个真实的调参经验把粒子系统的发射数量从 10 万减到 6 万帧率提升一倍视觉差异几乎看不出来。粒子不是越多越好很多粒子贡献的是冗余覆盖率一个像素上已经有 8 层透明片段时再叠加第 9 层对最终颜色的影响微乎其微。5.5 现象同一套代码在某一家的显卡上重影换平台又正常原因这类问题相对少见但遇到就非常耗时间通常出在三个地方。一是std430布局在不同驱动上实现有差异虽然规范统一但结构体里混用vec4和其他类型时对齐问题容易踩到老驱动 bug。二是 atomic counter 在部分移动端 GPU 上被模拟实现性能和语义有偏差。三是链表头纹理的 format 和 image unit 的 format 不一致比如纹理建的是GL_R32UIglBindImageTexture却传了GL_R16UI读写就乱套。解决把节点结构体拆成三个独立数组用 SoA 布局绕开结构体对齐layout(std430, binding 1) buffer NodePool { uvec4 nodeData[]; // xcolor(打包), ydepth, znext, w保留 };颜色和深度打包进uvec4后对齐规则非常明确不同平台上行为一致。检查glBindImageTexture的第五个参数format必须和纹理内部格式严格匹配一个是GL_R32UI另一个也要是GL_R32UI这是最常见的低级踩坑点。还有一类隐蔽错误是链表头纹理绑定了 image unit 之后又在某个地方把它当 sampler 绑定到纹理槽。一个纹理在同一帧里既当 image 又当 samplerOpenGL 会隐式插入内存屏障性能暴跌甚至报错。Pass 2 里用texelFetch从uimage2D读取就不会触发这种冲突。6. 验证正确性一个双面片测试与两个进阶方向第一步必须验证的不是性能是正确性。找一个简单场景两个半透明矩形一个红色 alpha 0.5一个蓝色 alpha 0.5互相穿插。用两套渲染顺序分别跑一遍把两次输出截图逐像素对比如果有任何像素不同说明你的链表 OIT 还有问题。正确的 OIT 输出必须和渲染顺序完全无关。这个测试的妙处在于它能把问题放大。渲染顺序交换后如果某个像素内链表的 head 变了但排序逻辑正确结果应该一一对应如果排序有 bug像素间的差异会非常明显尤其是两片矩形的交叉区域。我当时第一次跑这个测试时就翻车了问题不是链表写坏而是 Pass 1 忘了关GL_BLENDSSBO 里的颜色本身已经被混合过一次。验证通过后可以往两个方向进阶。第一个方向是把 Pass 2 改成 compute shader。每个线程组处理一片像素块先采样链表头纹理把节点收集到 shared memory再用更快的排序算法排序比如双调排序或 bitonic sort。这样能降低 Pass 2 的时间和最大链表长度带来的性能抖动。第二个方向是给透明物增加深度分层在 Pass 1 根据深度把节点分别挂到“近”“远”两条链表里Pass 2 先合成远层再合成近层。这种方法比全排序列O(n log n)更快适合粒子场景。做这套方案到现在我养成了一个习惯宁可先开大节点池、先写简单排序也不要在第一版就做花哨优化。OIT 本身就是个复杂玩法先保证输出正确再逐步压内存和排序开销。希望帮到你。本文还有配套的精品资源点击获取