GLSL向量运算详解：逐元素乘法与点乘的区别及实战应用

1. 为什么标题里要特别注明非点乘两个vec相乘时你的预期和GLSL的行为1.1 第一次在GLSL里写 color * light颜色却变得很怪很多人在刚接触WebGL着色器时都经历过这样一个瞬间在片元着色器里想把一个物体的基础颜色和光照颜色乘在一起于是很自然地写下了类似这样的代码vec3 baseColor vec3(0.8, 0.5, 0.3); vec3 lightColor vec3(1.0, 0.5, 0.75); vec3 finalColor baseColor * lightColor;你以为这是在做某种向量乘法或者更夸张一点你觉得这应该等价于点乘dot product结果应该得到一个亮度值。但实际输出到屏幕上的颜色是vec3(0.8, 0.25, 0.225)——也就是红色分量保持不变绿色分量被砍掉一半蓝色分量变成原来的不到三分之一。整个物体看起来像是被一层偏红的滤镜盖住了。这正是GLSL里算术运算符的默认语义所有基本算术运算符、-、*、/在作用于向量类型时都是逐元素component-wise进行的。也就是说vec不是一个数学意义上的整体箭头而是四个并列的数字寄存器运算符会把两个向量中处于相同位置的分量两两配对计算。这个行为和C语言里对结构体做不了运算完全不同也和线性代数教材里向量的点乘、叉乘完全不同它是GPU着色器语言独有的SIMD式直觉。这个非点乘的声明之所以重要是因为绝大多数从传统编程甚至是从数学课转过来的开发者对向量乘向量的第一反应都是点乘。而实际上GLSL把运算符号给了逐元素操作点乘则专门保留给了dot()函数。如果一开始没转过这个弯后面排查bug时会浪费大量时间。1.2 逐元素运算的直觉来源颜色、坐标和UV本来就是并列分量为什么GLSL要这样设计因为GPU渲染场景里向量几乎从来不是纯粹的几何向量而更像一组打包在一起的数据。拿颜色来说vec3(0.2, 0.6, 1.0)的三个分量分别对应RGB它们之间没有夹角或投影的关系你关心的只是每个通道各自的数值变化。再比如UV坐标vec2(0.5, 0.25)的的U和V是两个相互独立的坐标轴缩放时你希望U和V分别乘以对应的系数而不是把整个UV当成一个方向去求投影。生活化的类比你手里有两个水果礼盒每个礼盒里有三个格子分别装着苹果、香蕉、梨。逐元素乘法就是苹果乘以苹果、香蕉乘以香蕉、梨乘以梨——每个格子独立运算。而点乘则是先算出每一对的乘积再把这三个乘积加到一起最终得到一个单独的总分。这两个操作的应用场景完全不同前者用于调制后者用于度量。这篇博文讲的是前者但为了把边界划清楚第3章也会把后者拉出来对比。1.3 运算符行为速查表vec类型上的四则运算全解析下面这张表总结了GLSL ES中常用算术运算符作用于向量以vec3为例时的行为。所有运算都是左右分量一一对应结果仍然是一个vec3。表达式运算语义结果示例x0.6, y0.4, z0.2a b各分量相加(x1x2, y1y2, z1z2)a - b各分量相减(x1-x2, y1-y2, z1-z2)a * b各分量相乘(x1x2, y1y2, z1*z2)a / b各分量相除(x1/x2, y1/y2, z1/z2)float * vec标量广播到每个分量(fx, fy, f*z)vec * float同上乘法满足交换律(xf, yf, z*f)a % b整型各分量取模(x1%x2, y1%y2, z1%z2)对于二维和四维向量规则完全一致。也就是说vec2、vec3、vec4以及ivec、uvec整数向量都遵循这套逐元素语义。只要两个操作数的维度相同或者其中一个是标量编译器就允许运算。比如vec4 * vec4没问题vec3 vec3也没问题但vec3 * vec2会直接编译报错。理解了这张表你就拿到了打开WebGL着色器算术运算大门的钥匙。接下来我们在第2章深入几个容易翻车的细节尤其是那些在文档里一笔带过、但实际写代码时坑得你欲哭无泪的规则。2. 逐元素算术的语法细则与隐藏陷阱类型匹配、整数除法、取模符号和精度2.1 标量广播Scalar Broadcast为什么vec * float能工作逐元素运算最常用也最容易理解的一条规则就是标量和向量的混合运算。vec3(0.1, 0.2, 0.3) * 2.0会先把2.0复制成vec3(2.0, 2.0, 2.0)再做逐元素乘法结果自然是vec3(0.2, 0.4, 0.6)。这个复制操作在图形学里叫广播broadcast。你可能觉得这是理所当然的但值得强调的是GLSL并不会隐式地把标量转换成向量也不会隐式地把整数转成浮点数。vec * int在很多情况下是编译不过去的因为GLSL ES的类型检查非常严格。看这个错误vec3 color vec3(0.5, 0.5, 0.5) * 2; // error: int cannot be multiplied by vec3你需要写成2.0而不是2。这不是吹毛求疵——在高性能着色器里类型不匹配往往意味着着色器编译失败而编译失败在运行时只表现为黑色屏幕或控制台一条错误日志排查起来非常隐蔽。所以我的建议是写着色器代码时所有数值常量都带上小数点除非你明确在操作int或ivec。标量广播的实际应用非常广。顶点着色器里经常需要把时间float uTime和位置向量相乘比如让一个顶点沿x轴震荡vec3 pos position; pos.x sin(uTime) * 0.5; // float * float只影响x分量这里sin(uTime) * 0.5是标量运算再把结果加到pos.x上。另一种做法是用一个vec3方向乘以标量位移量一步到位vec3 offset vec3(0.0, 0.5, 0.0) * mod(uTime, 2.0); vec3 newPos position offset;第二种写法虽然看起来多创建了一个临时向量但GPU上的着色器编译器通常会把它优化成直接加法性能上没有任何损失代码的可读性却高很多。2.2 整数除法与浮点取模最容易写出看起来对、实际错的两处GLSL ES里int类型做除法时行为和C语言一样结果直接截断小数部分int result 5 / 2; // result 是 2不是 2.5这本身不难理解但坑在于很多人用了GLSL的取模函数mod()后误以为它能处理所有类型。看GLSL ES规范里的定义float mod(float x, float y) { return x - y * floor(x / y); }这个公式的意思是mod(x, y)的符号跟随y而不是跟随x。这和C语言中%运算符的符号规则符号跟随被除数 x完全相反。举个例子C语言-5 % 3的结果是-2符号跟随 -5GLSLmod(-5.0, 3.0)的结果是1.0因为 -5 - 3 * floor(-1.6667) -5 6 1对于做UV平铺、序列帧动画、周期性闪烁这些场景这个差异直接决定你的图案是连续的还是跳变的。如果你想要C语言风格的余数GLSL里需要自己实现float cMod(float x, float y) { return x - y * trunc(x / y); }或者直接用内置的trunc相关的运算替代。我在做循环滚动背景时踩过这个坑当时一个粒子系统里的mod(time, duration)在某些时间点突然出现数值负跳变查了很久才发现是符号规则和预期不同。关于浮点取模还有一个使用技巧mod(x, 1.0)可以用来快速截取一个浮点数的小数部分等效于fract(x)。但fract()的效率更高语义也更明确所以在片元着色器里做UV平铺时尽量用fract(uv * scale)而不是mod(uv * scale, 1.0)。2.3 精度修饰符移动端GPU上的数学陷阱WebGL着色器的精度问题非常隐蔽尤其体现在逐元素算术运算中。GLSL ES 允许你给浮点变量声明highp、mediump、lowp三种精度。桌面浏览器一般默认highp但移动端GPU的片元着色器如果不显式声明很多驱动会把浮点变量默认成mediump这意味着有效精度只有大约16位浮点。16位浮点能表示的范围大概只有-65504到65504而且小数位精度有限。在逐元素运算里如果做累加、做大范围UV偏移、或者用时间值做周期运算mediump很容易出现明显色带、闪烁或顶点抖动。典型场景是粒子系统粒子坐标随时间不断累加数值越来越大超出16位浮点的精确表示范围粒子就开始颤抖。解决办法是在顶点着色器和片元着色器开头显式声明precision highp float;如果是计算量特别大的片段也可以把某些关键中间变量单独声明为highp其余用mediump提升性能highp vec3 worldPos ...; mediump vec3 normal ...;不过要注意precision highp float;在片元着色器里对某些移动端GPU可能不支持。如果你的目标平台是老旧的Android设备又必须在片元着色器用高精度一个兼容做法是把高精度计算放到顶点着色器完成因为顶点着色器通常强制支持highp。这些细节虽然不属于算术运算符本身但直接影响逐元素运算结果的正确性顺带在这里提醒一句。3. 点乘dot到底做了什么几何意义、使用场景以及它和逐元素乘法的本质区别3.1 dot 的本质把一个vec压缩成一个标量点乘在GLSL里对应dot(a, b)它的定义是float dot(vec3 a, vec3 b) { return a.x * b.x a.y * b.y a.z * b.z; }从形式上看点乘的运算过程确实包含逐元素乘法——先算a.x * b.x等三个乘积然后再把三个结果加起来。关键差别就在最后一步点乘把向量变成了一个单一数值而逐元素乘法保留向量形态。这个差别不是形式上的而是语义上的根本不同。几何上如果a和b都是归一化向量长度为1那么dot(a, b)等于它们夹角的余弦值。当两个方向完全一致时结果等于1垂直时等于0相反时等于-1。这是图形学里几乎所有光照计算的基础——表面法线和光线方向的点乘决定了这个表面接收到多少光。用生活类比来理解逐元素乘法是两个装水果的礼盒逐格配对相乘你得到的仍然是每格装了什么的明细。点乘则是把每个格子的乘积算出来之后再统统倒进一个大筐里称重最后只得到一个总重量。一个是调制配方一个是测量结果。3.2 什么时候你真的需要点乘光照强度、归一化方向和判断朝向点乘在WebGL中最常见的使用场景有三类。第一类是漫反射光照。片元着色器里计算朗伯光照float NdotL max(dot(normal, lightDir), 0.0);这里normal和lightDir预先做了归一化。dot的结果就是光强系数乘以基础颜色就能得到明暗变化。如果把这里的dot改成逐元素乘法vec3 wrong normal * lightDir; // 得到的是 vec3不是光强你的光照模型就完全崩了——不仅得不到一个亮度数值而且那个vec3的每个分量都可能是负数再用max(vec3, 0.0)这种写法虽然能过编译但语义和真正的NdotL差了十万八千里。第二类是判断两个方向是否朝向同一侧。比如做轮廓检测或背面剔除时通过法线和视线的点乘符号判断当前片元朝前还是朝后。第三类是计算两个向量的夹角大小用于衰减、聚光灯锥角、边缘光等效果。比如聚光灯的边缘可以用dot(v, spotDir)和某个阈值做比较决定灯光从中心到边缘的衰减曲线。3.3 核心区别记忆法逐元素乘法调制点乘度量我总结了一套记忆法分享给刚入门的读者凡是需要把一个向量按另一个向量各分量去影响的结果用逐元素乘凡是需要问两个方向有多大角度、有多相似的结果用点乘。两者具体的对比如下维度逐元素乘法点乘输入两个维度相同的向量两个维度相同的向量输出仍然是向量一个标量float典型用途颜色调制、UV缩放、坐标偏移光照强度、夹角判断、投影长度几何含义无分量独立运算方向相似度的度量是否要求归一化不要求计算夹角时需要归一化函数形式vec * vec运算符dot(a, b)函数实际编码中还有一种常见混乱把逐元素乘法的结果和另一个向量再点乘比如计算投影长度dot(normalize(a), b)时有人会先写normalize(a) * b得到vec3后又不知道下一步该干嘛。正确的写法就是直接dot(normalize(a), b)一个函数搞定。出现这种困惑时回到记忆法你要的是度量不是调制。4. 实战在片元着色器里做手电筒光锥效果逐元素运算和dot的分工4.1 场景设计用基础数学模拟一个聚光灯衰减为了把前面两章的概念放在真实代码里验证我做了一个很小但完整的WebGL着色器实战在片元着色器里模拟一个手电筒光锥射在平面上的效果。先定义输入vUv平面UV坐标由顶点着色器从position.xy传递过来uCenter手电筒中心在UV中的位置uniform vec2uLightColor光照颜色uniform vec3uBaseColor地面基础颜色uniform vec3uTime用于产生轻微摆动的时间值光锥的亮度由两部分组成距离衰减和方向衰减。这里我们用逐元素运算处理前者的坐标偏移和距离范围用点乘处理后者的方向夹角。4.2 顶点着色器用逐元素运算做平面位移先看顶点着色器这里演示一个低频震荡位移attribute vec3 position; attribute vec2 uv; uniform float uTime; varying vec2 vUv; void main() { vec3 pos position; pos.x sin(uTime position.y * 3.0) * 0.05; // 逐元素参与的标量运算 pos.y cos(uTime * 0.8 position.x * 2.0) * 0.03; vUv uv; gl_Position projectionMatrix * modelViewMatrix * vec4(pos, 1.0); }这里的position.y * 3.0是标量乘标量加到pos.x上。它展示了逐元素运算的另一个常见面在顶点着色器中你通常通过单独修改pos.x、pos.y分量来达到位移目的而不是对整个向量做矩阵乘法。这种方式直观、开销小很适合做顶点动画。4.3 片元着色器逐元素调制颜色用点乘控制光强片元着色器是本文的核心完整代码如下precision highp float; varying vec2 vUv; uniform vec2 uCenter; uniform vec3 uLightColor; uniform vec3 uBaseColor; uniform float uTime; void main() { // 1. 向量偏移计算当前片元到手电筒中心的向量逐元素减法 vec2 toCenter vUv - uCenter; // 2. 轻微摆动让光锥抖动向量叠加 vec2 wobble vec2(sin(uTime * 2.0), cos(uTime * 1.7)) * 0.02; toCenter wobble; // 3. 距离衰减用向量点乘自己得到距离平方避免开方 float dist2 dot(toCenter, toCenter); float radius 0.3; float falloff smoothstep(radius, 0.0, sqrt(dist2)); // 4. 方向衰减模拟光锥的角度限制点乘归一化方向 vec2 lightDir normalize(vec2(0.5, 0.8)); // 手电筒的主方向 float dirFactor max(dot(normalize(toCenter 0.0001), lightDir), 0.0); dirFactor pow(dirFactor, 3.0); // 5. 逐元素乘法光照颜色和基础颜色逐通道调制 vec3 color uBaseColor * uLightColor; // 逐元素乘 color * falloff * dirFactor * 1.5; // 标量乘法 color clamp(color, 0.0, 1.0); // 逐元素clamp gl_FragColor vec4(color, 1.0); }逐步拆解这段代码的运算逻辑第1步和第2步是vec2的逐元素减法和加法目的是算当前位置的相对偏移完全不需要考虑向量几何。第3步很有意思dot(toCenter, toCenter)其实是在做逐元素自乘后求和得到距离平方。这步本质是点乘但目的是避开length()的平方根操作在衰减计算中更高效。这也说明了点乘并不总是单独存在它和逐元素运算经常配合使用。第4步用normalize和dot计算方向因子这个场景下非用点乘不可——因为要度量方向和夹角而不是调制分量。第5步回到uBaseColor * uLightColor这就是通篇的主角逐元素乘法让地面颜色和灯光颜色在每个RGB通道上独立混合。如果用点乘替换这一步会变成dot(uBaseColor, uLightColor)得到一个亮度值颜色信息就全丢了。4.4 实验结论与扩展玩法把同一个shader改成霓虹灯扫描这个手电筒例子跑通之后你可以试着把它改成霓虹灯扫描效果把dirFactor改成step(0.9, dirFactor)得到硬边把falloff改成1.0 - smoothstep得到中心暗边缘亮的环再加上uTime控制中心点移动。核心仍然是逐元素运算在调制颜色点乘在控制几何衰减。还有人会问这段代码里clamp(color, 0.0, 1.0)是对vec3做逐元素操作吗是。clamp在GLSL里对向量类型也是逐元素处理的它把每个分量单独压缩到[0,1]区间。这也是为什么在实际项目中我几乎不给color写if判断语句而是直接用clamp一步到位——GPU上的逐元素分支其实不便宜能向量化就向量化。5. 从WebGL context could not be created到着色器编译失败算术运算报错的完整排查链路5.1 环境问题GPU进程起不来和你的代码一点关系都没有很多初学者在Three.js里遇到下面这个错误第一反应是自己写的着色器代码有问题THREE.WebGLRenderer: A WebGL context could not be created. Reason: Web page was created with GPU process not available.完整报错常常是 Reason: Web page was created with GPU process not available 或 can not create webgl context。这个报错的意思是浏览器尝试创建WebGL上下文时GPU进程没能正常启动。原因基本都在环境层面和你的算术运算代码没有任何关系。常见原因有以下几种浏览器设置里关闭了硬件加速显卡驱动太老或已崩溃GPU进程无法初始化系统显存不足尤其同时开了多个大型3D页面物理GPU被其他进程占满或者处于节能模式浏览器标签页数量过多达到WebGL上下文数量上限Chrome一般限制16个左右。排查顺序建议先打开Chrome地址栏输入chrome://gpu查看WebGL相关的状态是否是Hardware accelerated。如果不是尝试关闭浏览器再重新打开、更新显卡驱动或者临时切换到大屏独立显卡。如果硬件加速正常但依然报错关掉几个占用GPU的标签页再试。如果你确定WebGL上下文创建失败是因为某个iframe或特定页面可以尝试在Three.js创建renderer时加上失败回退选项const renderer new THREE.WebGLRenderer({ canvas: canvas, powerPreference: high-performance, failIfMajorPerformanceCaveat: false, antialias: false });把failIfMajorPerformanceCaveat设为false的意思是在GPU性能不足时允许浏览器使用软件渲染SwiftShader。虽然帧率惨不忍睹但它能让你先验证着色器逻辑是否正确而不是被环境问题卡住。5.2 编译器报错实例运算符类型不匹配时提示怎么读当你从环境问题中解脱出来开始编译自己的着色器时最常见的算术错误是这样的ERROR: 0:12: * : wrong operand types: no operation * exists that takes a left-hand operand of type vec3 and a right-hand operand of type mat3 (or there is no acceptable conversion)这个报错的意思是你想让vec3乘以mat3但GLSL里不存在这样的运算符重载。如果你写过线性代数你会觉得vec3 * mat3应该是合理的——向量乘矩阵。但GLSL的规则是如果要乘矩阵必须使用*并且让vec3左乘矩阵时GLSL会自动当作行向量处理或者你写成mat3 * vec3。但这里的报错场景通常是用户混入了未知类型比如把两个不同维度的向量相乘vec2 uv vec2(0.5); vec3 color uv * vec3(1.0); // ERROR: * : dimension mismatch编译器会提示维度不匹配。遇到这类报错最快的检查顺序是确认两个向量的维度完全一致确认一个标量一个有小数点不要用整数常量直接乘向量确认没有误把矩阵类型mat2、mat3、mat4塞进*运算确认%只用于整数类型浮点取模必须用mod()。5.3 调试验证闭环把中间结果直接刷成颜色让错误一目了然着色器调试不像JS可以console.log但有一个非常有效的土办法把想要检查的中间变量直接赋值给gl_FragColor用颜色显示出来。这个办法对逐元素运算的验证特别有用。比如我想确认toCenter这个向量的x分量是不是0附近。可以临时写gl_FragColor vec4(toCenter.x, 0.0, 0.0, 1.0);屏幕上就会显示一张红色渐变的图——偏左的位置红色深负值截断为0偏右的位置红色浅中心区域黑色。这张图直接告诉你向量的分布情况比任何日志都好使。同样如果想验证uBaseColor * uLightColor是不是符合预期可以直接输出它gl_FragColor vec4(uBaseColor * uLightColor, 1.0);如果画面整体颜色和你手动计算0.8*1.0、0.5*0.5、0.3*0.75的结果一致说明逐元素运算的行为完全正常。这个用颜色做断言的调试闭环是我目前用过最有效的着色器排错手段。6. 一些我踩过坑之后的个人习惯着色器内算术运算的规范写法6.1 用 clamp、min、max 包住逐元素运算防止颜色越界颜色值超过[0,1]并不会导致程序崩溃但会呈现出无法预测的结果HDR渲染时超过1的高亮区域可能在后续tonemapping中被压缩而负值可能被硬件自动截断成黑色。所以我的习惯是只要做了逐元素乘法或加法紧接着就做一次clamp或smoothstep收边界。比如一个简单的辉光叠加vec3 base texture2D(uTex, vUv).rgb; vec3 glow vec3(0.2, 0.5, 0.9) * uIntensity; vec3 finalColor clamp(base glow, 0.0, 1.0);clamp接受三个参数当第一个参数是vec3时后面两个标量会自动广播到每个分量。这种写法比逐个分量判断干净得多GPU向量指令也更快。不过要留意一个边界情况clamp会把中间计算结果强制截断如果你之后还要继续做 HDR 合成可能希望保留超过1的亮度。这时候就应该把clamp推迟到最后一步中间过程用min或max做单项约束即可。6.2 把多次逐元素乘法合并成一个表达式减少uniform数量在创建一个材质系统时我倾向于把皮肤/金属/粗糙度等参数合并成向量一次性传给着色器而不是定义五个float uniform。例如uniform vec3 uMaterialParams; // x 金属度, y 粗糙度, z 环境光强度在片元着色器里用uMaterialParams.x、uMaterialParams.y、uMaterialParams.z访问分量。这种做法的好处是减少uniform上传次数也让逐元素运算的语义更集中——因为参数之间本来就要做大量分量独立的乘加运算用向量存储可以在一个表达式里同时完成多次操作。比如调整一个颜色时vec3 albedo texture2D(uAlbedo, vUv).rgb; vec3 modulated albedo * uMaterialParams; // 逐元素乘法一次指令处理三个通道如果你的uMaterialParams三个分量分别是亮度、对比度偏移、饱和度系数逐元素乘法的威力就体现出来了——三个通道一行代码搞定。如果用三个float uniform你反而得写三行而且容易漏掉某个分量。6.3 最后的建议把vec想成并排的数字寄存器而不是箭头写WebGL着色器两年后我发现一个思维习惯比任何API知识都有用在GLSL里vec的第一身份是寄存器组第二身份才是几何向量。这意味着看到vec3时不要下意识认为它代表空间里的一个方向或位置。它可能表示颜色RGB、UV、权重、法线或者干脆就是三个无关紧要的温度值。正因为如此逐元素运算才成为GLSL的默认行为——它是通用数据并行运算的最小单元。而点乘、叉乘、矩阵乘法这些几何操作则是构建在逐元素运算之上的语义层。你先掌握好这个寄存器组的直觉再去看光照、位移、形变等复杂着色器就会顺畅得多。如果你决定继续深入WebGL下一步建议去研究mat4矩阵运算和transform的配合以及顶点着色器中的逐顶点属性插值。不过那就是另一篇博文的主题了。这篇先到这Go write some shaders。