1. 从一盏灯到一套计算模型光照贴图背后的渲染逻辑在Android上做3D渲染绕不开OpenGL ES。不少人一开始接触光照贴图Light Mapping时会把注意力全放在“贴图”两个字上以为只是把一张纹理换得更漂亮。实际跑过项目的人都知道光照贴图的关键反而不在贴图本身而在“光照”的计算链路是否在着色器里真正立住了。它处理的是这样一件事模型表面的每个像素点收到场景中各个光源的多少光最终以什么颜色呈现把这些信息通过纹理坐标采样出来合入最终颜色输出。先花点时间把光照贴图的本质说清楚。传统漫反射贴图负责提供物体表面的“固有色”比如一面砖墙的红色、一件衣服的蓝色。光照贴图则是把“光打在表面上的结果”预先或实时计算出来存成纹理再和漫反射贴图相乘叠加。这样做的好处非常明显大量静态光源的贡献可以烘焙成一张贴图运行时少算几十上百次光源迭代电池和帧率都扛得住。反过来在需要动态交互的场景里光照贴图也可以由实时Shader计算产生根据需要调节光的强度、方向、颜色而不必每帧都重新烘焙。这里就引出光照计算的基本模型。程序里最常用的是Phong模型实际访问中使用Blinn-Phong的情况也很多它把一束光的贡献拆成三块环境光Ambient、漫反射光Diffuse、镜面高光Specular。环境光是没有方向感的基底亮度保证物体背光面不至于死黑漫反射是光打到粗糙表面后向四面八方散射的部分强度跟光线方向和表面法线之间的夹角的余弦成正比镜面高光则是光滑表面把光集中反射到某个方向的部分跟视线方向、光反射方向都有关系。用GLSL写成片元着色器大概长这样// 片元着色器Phong光照模型核心计算 uniform vec3 uLightPos; // 光源位置世界空间 uniform vec3 uViewPos; // 相机位置世界空间 uniform vec3 uLightColor; // 光源颜色 uniform sampler2D uDiffuseTexture; // 漫反射贴图 uniform sampler2D uSpecularTexture; // 镜面高光贴图光照贴图的一种形态 varying vec3 vFragPos; // 片元位置 varying vec3 vNormal; // 法线已变换到世界空间 varying vec2 vTexCoord; // 纹理坐标 void main() { vec3 texColor texture2D(uDiffuseTexture, vTexCoord).rgb; vec3 specTex texture2D(uSpecularTexture, vTexCoord).rgb; // 环境光 float ambientStrength 0.15; vec3 ambient ambientStrength * texColor; // 漫反射 vec3 norm normalize(vNormal); vec3 lightDir normalize(uLightPos - vFragPos); float diff max(dot(norm, lightDir), 0.0); vec3 diffuse diff * uLightColor * texColor; // 镜面高光 vec3 viewDir normalize(uViewPos - vFragPos); vec3 reflectDir reflect(-lightDir, norm); float spec pow(max(dot(viewDir, reflectDir), 0.0), 32.0); vec3 specular spec * uLightColor * specTex; gl_FragColor vec4(ambient diffuse specular, 1.0); }这段代码是把光照贴图跑通的最小骨架。可以看到漫反射贴图采样出来的颜色参与漫反射计算镜面高光贴图采样出来的颜色参与高光计算。实际操作里很多人会犯一个错误漫反射贴图和“光照贴图”到底哪个是哪个先把概念搞混。光照贴图更泛的说法是将光照计算结果预存为纹理而镜面高光贴图则专门控制表面哪些区域反光强、哪些区域反光弱是光照贴图体系中很实用的一种。一栋建筑的窗玻璃区域镜面贴图里就是亮色砖墙区域就是暗色这个信息如果是实时算的面片要多做几十次反射计算做成贴图后Shader里只多了一条texture2D采样指令性能差距肉眼可见。那是不是说只要把贴图接上去光照就自然对了远不是。光照计算要出正确效果还有两个前置条件模型法线必须是正确的法线变换必须考虑非均匀缩放纹理坐标必须跟模型UV对齐否则采样出来的光照信息会张冠李戴。这正是下一节要展开的坑。2. 法线变换光照计算里最容易翻车的一步经常听到有同学说光照代码明明跟教程一模一样可渲染出来的效果就是不对亮点位置偏了、暗部阴阳脸、高光边缘闪。排查半天九成问题出在法线变换上。这里先讲原因。OpenGL ES里的模型顶点坐标和法线通常定义在模型本地坐标系。顶点在送入渲染管线时会经过模型矩阵变换到世界空间。顶点坐标用模型矩阵直接乘没问题但法线不能直接乘。法线不是定位点它是方向向量平移对坐标有影响对方向向量没有。更关键的是如果模型矩阵里包含了非均匀缩放比如X轴放大2倍、Y轴放大1倍直接乘会让法线与表面不再垂直光照计算立刻出错。图形学里的标准做法是用法线矩阵即模型矩阵的逆转置矩阵去变换法线。有基础的同学会说知道了法线矩阵等于inverse(transpose(model))。这在OpenGL 3.3及以上可以用mat3(transpose(inverse(model)))直接算但在OpenGL ES 2.0/3.0的GLSL里是不支持在着色器里直接求逆矩阵的。所以必须在CPU侧把法线矩阵算好作为uniform变量传入。实际项目里我在Android上处理法线变换有几种做法只在CPU算出法线矩阵传入Shader。用Matrix.invertM和transposeM组合在Java/Kotlin里求出逆转置矩阵再上传为uNormalMatrix。如果模型矩阵只有旋转和平移且缩放是均匀的直接取model矩阵的3x3主对角块当法线矩阵也可以因为均匀缩放只会改变法线长度归一化之后等于没变。为了节省开销可以检测矩阵的缩放分量统一缩放就用3x3矩阵非统一缩放才用逆转置。在顶点着色器里手动实现逆转置这是最后的手段不推荐因为GLSL ES不支持复杂矩阵运算代码写起来又慢又容易出错。在第1种做法下CPU侧的Kotlin代码大致是val normalMatrix FloatArray(16) Matrix.invertM(normalMatrix, 0, modelMatrix, 0) // 求逆 Matrix.transposeM(normalMatrix, 0, normalMatrix, 0) // 转置 GLES20.glUniformMatrix4fv(uNormalMatrixLoc, 1, false, normalMatrix, 0)然后在顶点着色器里把法线变换到世界空间varying vec3 vNormal; // ... vNormal mat3(uNormalMatrix) * aNormal;这里有个细节mat3(uNormalMatrix)从4x4矩阵里取出左上角3x3子矩阵这不影响旋转和缩放分量的变换平移分量天然被丢掉正好符合法线需求。再补充一个容易搞混的点法线到底是变换到世界空间还是观察空间。两种都能算出光照但观察空间的计算要额外把光源位置和相机位置都转到观察空间坐标变换链路多一环世界空间计算更直观debug更方便。实际项目里常用世界空间但记住法线矩阵和模型矩阵用的是同一个变换空间不能今天用世界空间明天用模型空间渲染结果必然漂。我建议在项目启动第一天就把空间约定写成注释贴在着色器文件头部省得两周后自己都忘了。如果法线变换搞错了最典型的现象是静态物体不动旋转相机时光照亮点跟着相机跑。这是因为法线跟视线方向计算出的夹角被扭曲了反射方向完全错乱高光位置不稳定。排查时先关掉镜面高光只保留漫反射把环境的底色调成纯黑然后绕物体转一圈看明暗分布是否符合直觉。如果明暗不随光源方向变化法线矩阵八成是传错了或者没有乘。我之前做过一个某图像处理Demo的自定义模型顶点数据是从外部工具导出的法线在导出时没重新计算结果模型表面法线全是零向量。光照算出来一片黑排查很久才发现问题不在Shader而在模型源数据。这里也给大家一个建议拿到模型之后先写一个小工具把法线长度输出一遍检查是否有非法值或者零向量没有这一步Shader写得再好也白搭。3. Android侧的材质数据管线纹理、着色器与渲染状态光照计算的底层逻辑理清了接着就是把数据灌进GPU。Android上的OpenGL ES应用核心是由GLSurfaceView承载渲染循环实际开发时大部分人会用GLSurfaceView.Renderer接口来管理绘制。这一步的关键不是调用几个API而是把“贴图数据”和“渲染状态”在正确的时机绑定上去。3.1 EGL环境的建立与渲染线程的坑先简单说一下EGL。EGL是OpenGL ES与Android窗口系统之间的桥梁负责创建渲染表面、配置上下文。GLSurfaceView内部已经帮你封装好了EGL环境但如果你用了TextureView或者SurfaceView自建渲染管线的路子就需要手动管理EGLContext、EGLDisplay、EGLSurface。大部分光照项目用GLSurfaceView就够除非你要做多种渲染API混用才能体会到自己管EGLContext的重要性。在GLSurfaceView的配置上有一个容易忽略的选项setEGLContextClientVersion(2)和setEGLConfigChooser(8, 8, 8, 8, 16, 0)。前者告诉EGL我们要用OpenGL ES 2.0后者要求颜色缓冲区RGBA各8位、深度缓冲16位。光照贴图项目一般需要一个合理的深度缓冲不然物体前后遮挡关系会乱光照打在后面的物体上也会错误地显示在前面。3.2 纹理加载方向、格式、mipmap三座山光照模型里的贴图进入GPU走的是一条标准的纹理加载流程。Android里最常见的方式是用Bitmap加GLUtils.texImage2D但真实项目中小心三点纹理翻转问题。Bitmap的内存排列从左上角开始OpenGL的纹理坐标系原点默认在左下角如果设置了GL_TEXTURE_COORDINATE标准默认约定不同但实际用默认值的话大概率要处理。最稳妥的做法是在加载时预先翻转Bitmapval matrix Matrix() matrix.postScale(1f, -1f) val flipped Bitmap.createBitmap(bitmap, 0, 0, bitmap.width, bitmap.height, matrix, true)或者在着色器里把纹理坐标的v分量反转uv vec2(texCoord.x, 1.0 - texCoord.y)。两种方式选一种别两个都用否则纹理上下颠倒后再翻一次等于没翻。我在项目里习惯统一在Bitmap加载处翻转这样着色器代码更干净多一个步骤但后续维护省心。格式问题。光照贴图如果包含强度信息尽量用线性空间处理避免直接把sRGB图片当线性值计算。Android的Bitmap默认解码出来的颜色空间可能是sRGB如果你追求拟真光照建议在解码时显式转换或者用GL_EXT_texture_sRGB扩展。但移动端对这个扩展的支持并不一致项目里追求效果的时候常常直接解码成RGBA_FLOAT纹理显存占用翻倍属于正常换来的是颜色计算更可控。如果性能吃紧退回到8位纹理加手动Gamma校正也可以。mipmap。光照贴图被缩小时顶点生成的纹理坐标落在像素之间没有mipmap会产生大量闪烁噪点。可以用GLES20.glGenerateMipmap(GL_TEXTURE_2D)自动生成再把纹理过滤方式设置成GL_LINEAR_MIPMAP_LINEAR。注意生成mipmap的前提是纹理尺寸为2的幂。现在很多格式比如压缩纹理不要求2的幂但mipmap通常还是需要。Android上加载的位图尺寸经常不是2的幂需要先做Bitmap.createScaledBitmap幂2化流程或者接受无mipmap的锯齿。这个取舍要提前想清楚别到了压帧率时回头改纹理。3.3 着色器编译与uniform绑定顺序光照贴图Shader的编译过程和普通Shader没有本质区别但uniform数量变多了位置、颜色、纹理、法线矩阵各占一个uniform位置。Android的glGetUniformLocation在每次链接后都要重新获取因为程序重新编译链接后uniform位置可能变化。很多人会在onSurfaceCreated里缓存uniform位置这没问题但前提是Shader程序没有在运行中被重新构建。更隐蔽的一个坑是纹理单元的绑定。片元着色器里有多个采样器比如漫反射贴图采样器和镜面贴图采样器就要用glActiveTexture(GL_TEXTURE0)和glActiveTexture(GL_TEXTURE1)分别激活再把纹理ID绑定到对应单元最后给每个采样器设置对应的纹理单元编号GLES20.glActiveTexture(GLES20.GL_TEXTURE0) GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, diffuseTexId) GLES20.glUniform1i(uDiffuseTexLoc, 0) GLES20.glActiveTexture(GLES20.GL_TEXTURE1) GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, specularTexId) GLES20.glUniform1i(uSpecularTexLoc, 1)顺序不能乱。如果先绑定了纹理后激活纹理单元那纹理实际绑定到的还是之前激活的单元采样器就可能采到错误贴图。这种问题渲染出来往往是颜色混乱、贴图串台排查起来比法线问题还隐蔽因为程序根本不会报错。3.4 绘制循环中的数据同步节奏光照贴图一个重要特征是每帧要更新光源位置、相机位置等uniform。这些数据更新与顶点数据更新同步进行。我用的是一个简单的渲染循环结构onDrawFrame开头更新MVP矩阵和法线矩阵更新光的位置和颜色uniform绑定纹理单元绘制模型顶点处理交换缓冲。这里需要注意帧率与数据一致性问题。如果渲染线程和UI线程同时修改光源位置就需要加锁或采用双缓冲结构。我见过有人直接在主线程开一个Thread循环改uniform渲染线程读的时候读到半个更新的数据图像撕裂或者高光闪烁。严格来说渲染循环里所有uniform更新都应该在渲染线程内完成数据从UI线程通过ConcurrentLinkedQueue或者简单volatile传递避免跨线程直接写入GL状态。4. 调通光不亮、贴图花屏真机调试的高频故障清单光照贴图内容在模拟器里跑通了上真机就翻车这事儿太常见了。移动GPU的驱动实现跟桌面GPU有差异加上Android设备碎片化很多问题只在特定芯片上出现。这里梳理几个我实际踩过的高频故障每一个都包括现象、原因和解决办法。4.1 光不亮或整体偏暗现象场景里明明有光源模型也正确贴了纹理但渲染出来就是暗甚至全黑。原因排查路径光源位置检查。uLightPos - vFragPos如果方向和法线夹角超过90度max函数会把它截成0漫反射就是0。把光源拉到模型正面方向看是否恢复亮度。光源颜色是否传成了0。有些代码在初始化uniform时传默认值0忘了在每帧更新结果光颜色全0只有环境光。法线是否归一化。顶点着色器里没做normalize片元着色器做了但法线长度不是1漫反射系数被压缩。我统计下来前两个原因占了八成。排查办法很简单写一个调试模式的Shader直接把法线向量输出为颜色gl_FragColor vec4(normal * 0.5 0.5, 1.0)。如果模型表面呈现出平滑的红绿蓝渐变说明法线数据没问题如果看到大片纯色或者混乱色块法线链路有问题。这个调试技巧几乎每周都在用。4.2 贴图花屏或颜色错乱现象模型表面出现彩虹色条纹、相邻三角形亮度跳变、整体偏紫。常见原因现象原因解决彩虹条纹纹理压缩格式不匹配用RGBA加载了ETC压缩纹理统一纹理格式或查询GL_EXT_texture_compression_etctwo再进行加载整体偏紫纹理带宽Alpha通道但Shader输出时把Alpha当颜色混合检查glBlendFunc配置光照贴图模式通常不需要混合亮度跳变纹理坐标精度不足移动GPU的mediump精度不够在高光计算的uniform声明中改用highp精度纹理错位贴图方向翻转逻辑搞混统一到Bitmap翻转删掉Shader里的uv翻转由于移动端GPU的mediump浮点数在部分芯片上只有16位精度光照计算时高光指数pow的底数或者指数很容易被截断产生明显带状色块或者亮度跳变。光照贴图的Shader里为了避免这类精度问题我习惯把position、normal、lightDir这些关键变量声明为highp精度换性能的代价在移动端是值得的。4.3 高光闪烁或大面积高光消失现象转动相机时高光好像“呼吸”一样一会儿有、一会儿没有甚至高光范围突然变大或消失。这种问题多半出现在镜面贴图的采样坐标异常或者高光指数的指数值因为精度被打折。排查顺序先固定相机不动旋转光源看高光是否稳定变化然后固定不动直接改指数一个像素一个像素观察最后单独看镜面贴图确认它的UV映射没有失真。如果镜面贴图本身有黑色噪点那就不是Shader问题是贴图资源问题用图像工具检查一下通道内容就明白了。4.4 一个真实的分步排查示例我记得有一次项目X在测试机上出现“模型侧面全黑转动到某个角度突然全亮”的现象效果非常诡异。当时没有怀疑法线矩阵因为静态模型没旋转以为矩阵不需要更新。但实际代码里模型虽然没有整体旋转顶点动画或者skin的骨骼矩阵会改变局部法线方向法线矩阵没有跟着骨骼更新所有法线都停留在绑定姿势。这一问题在骨骼动画模型的光照贴图项目里很容易踩。解决方式是把骨骼矩阵合并进法线矩阵再上传而不是单传模型矩阵的逆转置。所以排查光照问题不要只看一个环节要把整个变换链路的每一步都在log里打出来模型矩阵、法线矩阵、光源位置每一步的数值都核对上问题通常很快就暴露了。4.5 真机与模拟器表现不一致模拟器上效果完美真机上花屏、闪烁高概率是以下原因模拟器用CPU模拟GPU精度和实现跟真机驱动完全不同真机GL扩展支持不同比如纹理压缩格式不一样真机Progressive Power Saving模式省电自动调节渲染负载导致帧率不稳定。解决办法就是尽量准备两台真机一台旗舰芯片一台老旧入门机用入门机压底线。光照贴图的渲染效果可以打折但程序不能闪退、不能花屏这样才能上量。在项目交付前最好在至少两档设备上跑一遍同一个场景发现问题优先级不同。5. 从静态光照到实时可调把光照贴图玩成一套可维护的光照卡光照贴图做到能渲染出正确效果只是第一步。在项目里维护一段时间你会发现零散的Shader、散落的uniform变量和几张贴图资源如果不好好组织两三个月后自己都不愿意碰那段代码。我推荐一种“光照卡Lighting Card”的组织方式把每一组光源、贴图、参数打包为一个结构体对象通过接口暴露给上层场景逻辑。一个光照卡大致包含光源颜色、位置/方向、光强、漫反射贴图引用、镜面高光贴图引用、法线贴图引用有的项目需要、环境光强度、各类开关标志。在Java/Kotlin侧用数据类来定义data class LightingCard( var lightColor: FloatArray floatArrayOf(1f, 1f, 1f), var lightPosition: FloatArray floatArrayOf(0f, 5f, 0f), var intensity: Float 1f, var diffuseTextureId: Int 0, var specularTextureId: Int 0, var ambientStrength: Float 0.2f, var shininess: Float 32f )渲染时只需遍历所有光照卡逐个设置uniform并重绘模型。要注意的是移动端GPU对DrawCall数量敏感每一个光源都意味着一次重新绑定uniform和可能的重绘指令。光照卡数量少比如1-2个完全没问题数量多到10个以上就要考虑多光源合并或者延迟渲染了那是另一个大话题。针对光照贴图的场景我的经验是把静态光全部烘焙到贴图动态光数量控制在2个以内这样兼顾效果和性能。再聊聊可调整性。贴图模式的优势是省算力劣势是实时调整光照参数不如纯着色器灵活。光照贴图项目里为了兼顾调试体验可以在Renderer里加一个“实时调整模式”光源参数改变时不走贴图采样直接走Phong计算结果等调好效果切回贴图模式让Shader采样光照贴图并比较两种模式的一致性。这个方法在项目初期特别有用既能看到精确算法的效果好光照贴图效果又能快速定位贴图烘焙中的颜色偏差。着色器里要做这种切换可以在uniform里加一个开关uniform int uUseLightMap; // 1使用光照贴图0使用实时计算 if (uUseLightMap 1) { gl_FragColor texture2D(uLightMapTexture, vTexCoord); } else { gl_FragColor computePhongLighting(); }这种if分支在GPU上是最便宜的uniform分支运行期一致不会造成大幅性能回退可以放心用。等场景定稿后把开关写死成1编译进第二个Shader变体还能省一个if判断。光照贴图的一大优势是风格的一致性。光照计算在实时运算时Shader的精度、贴图压缩都会造成轻微的颜色偏移而预烘焙光照贴图时所有光照信息被固化在固定贴图里渲染输出稳定不同设备之间观感差异小。这也让它非常适合做场景氛围统一的游戏或可视化App。缺点是贴图分辨率受限远看没问题近看时一张512宽度右上角可能覆盖大面积墙第一人称视角怼脸时颗粒感明显。解决方式是增加贴图分辨率或拆分贴图区域就是资源量和管理成本的提升了按项目尺度权衡即可。做光照渲染没有捷径每一个错误的渲染结果背后都有明确的数据链路问题。把法线变换、贴图管线、uniform状态和渲染循环这四件事理清楚再怪异的渲染问题也能逐一拆掉。最后分享一个我自己的调试习惯每次改动光照贴图相关代码之后先跑一个单物体的最小场景光源固定在模型右上45度方向漫反射贴图和镜面高光贴图用纯色测试图确认输出符合预期后再进入正式场景。这个流程帮我节省了大量排查时间也建议刚接触光照渲染的开发者把最小复现场景固定住它比任何教程都能让你更快掌握OpenGL ES光照贴图的脾气。