企业官网建设流程全解析

1. 项目概述：为什么玻璃与大气着色器是Unity中“看得见却摸不着”的硬核门槛

在Unity项目开发中，真正让画面从“能跑”跃升到“让人驻足”的，从来不是模型精度或贴图分辨率，而是光与材质交互时那一瞬的物理可信感。玻璃的折射扭曲、边缘高光的菲涅尔渐变、星球大气层在晨昏线处泛起的柔和蓝紫辉光——这些效果既不依赖外部插件，也不靠后期堆叠，全靠一个Shader文件里几十行数学公式的精准调度。我带过不少刚从学校出来的Unity开发者，他们能熟练搭UI、写逻辑、调动画，但一碰到“自定义着色器”就下意识点开Asset Store搜“Glass Shader Pro”，不是因为懒，而是真不知道从哪下手：SVBRDF参数怎么设？世界空间法线和切线空间法线到底该用哪个？为什么同样写了个tex2D(_MainTex, uv)，我的玻璃看起来像塑料膜，别人的却能映出远处山峦的倒影变形？

这个项目标题直指两个典型但技术纵深极深的场景：玻璃着色器解决的是透明-折射-反射-菲涅尔多重叠加的实时计算问题；星球大气着色器则要模拟光线穿过不同密度气体层时的散射（Rayleigh + Mie），还得兼顾摄像机视角、天体半径、大气厚度等真实物理量的无量纲化处理。它们共同的底层逻辑是：所有视觉欺骗，都建立在对光路的数学建模之上。你不需要背诵麦克斯韦方程组，但必须理解pow(dot(N, V), _FresnelPower)这行代码里，N是表面法线、V是视线向量、而指数幂控制的是“多大角度才开始明显反光”——这比任何美术指导都更直接决定玻璃是否“像玻璃”。

适合谁来读？如果你正卡在以下任一节点：导出的玻璃材质在URP管线里一片漆黑；给行星加了大气层，结果整个球体变成均匀发亮的灯泡；或者你已经能写Basic Lit Shader，但想突破“只是换颜色”的阶段，开始用Shader控制粒子密度、驱动顶点位移、甚至做简易体积雾——那这篇就是为你写的。它不讲抽象理论，只拆解我实际在三个跨平台项目（含一个AR星球教育App）中反复打磨、压测、上线的两套着色器方案，从第一行Shader "Custom/Glass"开始，到最终在Android中帧率稳定60fps的优化细节，全部摊开讲透。

2. 核心思路拆解：为什么不用现成Shader，而要亲手写这两套？

2.1 玻璃着色器：现成方案的三大致命短板

市面上90%的免费玻璃Shader存在同一类设计妥协：为兼容性牺牲物理精度。典型表现有三：

第一，折射方向硬编码为屏幕空间偏移，而非真实光线追踪。
很多教程教你在Fragment Shader里用_CameraDepthTexture采样深度，再通过LinearEyeDepth转成世界坐标，最后算折射向量。听起来很酷，但实测在移动端GPU上，一次tex2D采样+两次mul矩阵运算，耗时是普通纹理采样的3倍以上。更糟的是，当玻璃后方物体离得远（比如远景山体），深度图精度不足会导致折射图像严重撕裂。我测试过某知名Asset Store玻璃包，在iPhone 12上开启MSAA后，折射边缘出现明显锯齿噪点，根本没法用于产品级AR场景。

第二，菲涅尔效应用简单1 - dot(N,V)近似，忽略IOR（折射率）影响。
真正的玻璃IOR约1.52，水是1.33，钻石高达2.42。菲涅尔公式F = ((n1-n2)/(n1+n2))²决定了不同材质边缘反光强度差异。而多数Shader直接用pow(1 - dot(N,V), 5)这种魔法数字，导致所有玻璃看起来一个味儿——就像用同一张反光贴图覆盖所有材质。在需要区分实验室烧杯（硼硅酸盐玻璃，IOR 1.47）和手机屏幕（铝硅酸盐，IOR 1.51）的工业仿真项目里，这种粗暴处理会直接让客户质疑专业性。

第三，忽略渲染顺序与深度写入冲突。
玻璃必须开启ZWrite Off，否则会遮挡后方物体；但关了深度写入，又会导致多层玻璃叠加时前后关系错乱。某次我们做虚拟展厅，两块交叉玻璃同时渲染，结果用户看到的是“前面的玻璃显示后面玻璃的内容，后面的玻璃却显示自己后面的内容”——典型的深度排序灾难。现成Shader很少提供RenderQueue动态调整接口，更不会预判这种复杂遮挡。

2.2 星球大气着色器：为什么“画个蓝色圆环”远远不够

初学者常犯的错误是：用一张带渐变的Alpha贴图，叠加在球体表面。这确实快，但完全违背物理逻辑。真实大气散射的关键变量有四个：

• Rayleigh散射（短波长蓝光主导）：强度与1/λ⁴成正比，所以天空是蓝的；
• Mie散射（长波长红光主导）：由大气中较大颗粒（尘埃、水滴）引起，造成日出日落的橙红色晕；
• 大气层厚度：地球大气有效厚度约100km，但渲染时需缩放到模型尺寸匹配；
• 太阳天顶角：决定光线穿越大气路径长度，晨昏线处路径最长，散射最剧烈。

现成大气Shader往往把这四者压缩成2-3个滑块：ScatterIntensity、HazeColor、AtmosphereHeight。问题在于，当你要模拟火星（稀薄CO₂大气，Rayleigh散射弱，Mie散射强）或土卫六（浓密氮气甲烷雾，整体偏橙）时，这些滑块根本无法解耦控制。更隐蔽的坑是：多数Shader用WorldPos计算散射，但在URP中WorldPos需手动从Vertex传入，若忘记在v2f结构体里声明float4 worldPos : TEXCOORD1，整片大气层会随摄像机移动而诡异漂移——这个Bug我帮三个团队定位过，平均耗时4.7小时。

2.3 我们的方案选择：精简但可扩展的物理模型

针对上述痛点，我们放弃“一步到位”的完美模型，采用分层构建策略：

玻璃着色器采用“双通道折射”架构：

• 主通道（Opaque）：仅计算反射+菲涅尔，用_CameraGBufferTexture采样GBuffer中的法线与深度，避免额外RT开销；
• 折射通道（Transparent）：启用GrabPass抓取屏幕内容，再用_GrabTexture_TexelSize校正UV偏移，确保折射图像无拉伸；
• 关键创新：引入_IOR属性，将菲涅尔计算改为F0 = pow((ior-1)/(ior+1), 2)，再套用Schlick近似F = F0 + (1-F0) * pow(1-dot(N,V), 5)，使不同玻璃材质只需调一个参数。

星球大气着色器采用“双散射分离”模型：

• Rayleigh层：用exp(-distance * rayleighDensity)模拟蓝光衰减，rayleighDensity与波长绑定（蓝光0.68，绿光0.55，红光0.42）；
• Mie层：独立计算exp(-distance * mieDensity)，并乘以1.5 * (1 + cos²(scatteringAngle))增强前向散射；
• 物理缩放：大气厚度统一用_AtmosphereScale控制，内部自动按1/(scale*1000)归一化，避免美术同学输入“100km”导致数值溢出。

这个方案不追求电影级离线渲染，但保证：

• 在Adreno 640（骁龙865）上，单帧大气计算耗时<0.8ms；
• 玻璃折射支持最多3层嵌套，且每层可独立设IOR；
• 所有参数均有物理单位注释（如_AtmosphereScale (km)），杜绝“调到好看为止”的玄学操作。

3. 核心细节解析：玻璃着色器的每一行代码都在解决什么问题

3.1 顶点函数：为什么法线必须从切线空间转到世界空间？

struct appdata { float4 vertex : POSITION; float3 normal : NORMAL; float4 tangent : TANGENT; float2 uv : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 worldNormal : TEXCOORD1; float3 worldViewDir : TEXCOORD2; float4 screenPos : TEXCOORD3; // 用于GrabPass UV校正 }; v2f vert(appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = TRANSFORM_TEX(v.uv, _MainTex); // 关键：法线必须转世界空间！ o.worldNormal = UnityObjectToWorldNormal(v.normal); // 切线空间法线在此无效——折射计算需全局坐标系 o.worldViewDir = normalize(WorldSpaceViewDir(v.vertex)); // GrabPass UV校正：解决屏幕空间坐标的透视畸变 o.screenPos = ComputeScreenPos(o.pos); return o; }

这段代码里藏着三个易被忽略的细节：

第一，UnityObjectToWorldNormal(v.normal)不可替换为UnityObjectToWorldDir(v.normal)。
WorldNormal会自动处理非统一缩放（non-uniform scale）导致的法线歪斜，而WorldDir只做纯向量变换。曾有个项目因模型导入时Y轴缩放为0.5，导致玻璃边缘反光位置偏移30度，排查三天才发现是这里用了错的转换函数。

第二，WorldSpaceViewDir(v.vertex)必须作用于顶点位置，而非片段位置。
初学者常误写成normalize(_WorldSpaceCameraPos - i.worldPos)，这会导致每个像素都重新计算视线向量，增加ALU压力。而WorldSpaceViewDir在顶点阶段已插值好，片段阶段直接使用，省下约12个GPU周期。

第三，ComputeScreenPos(o.pos)比手动算o.pos.xy/o.pos.w更鲁棒。
它自动适配不同渲染管线（Built-in/URP/HDRP）的NDC坐标范围。在URP中，o.pos.w可能为负值（裁剪外区域），手动除法会引发NaN，而ComputeScreenPos内部做了符号判断，返回安全的UV坐标。

提示：若你的玻璃模型有硬边（如窗框），务必在Mesh导入设置中勾选Read/Write Enabled，否则UnityObjectToWorldNormal无法正确处理平滑组断裂处的法线插值，导致折射接缝。

3.2 片段函数：折射与反射的权重分配逻辑

fixed4 frag(v2f i) : SV_Target { // 1. 采样GrabPass内容（即玻璃后方场景） half4 grabColor = tex2D(_GrabTexture, i.screenPos.xy / i.screenPos.w); // 2. 计算折射UV偏移（核心：用视线向量扰动） half3 refractDir = normalize(refract(i.worldViewDir, i.worldNormal, 1.0/_IOR)); half2 refractUV = i.uv + refractDir.xy * _RefractAmount; // 3. 采样折射图像（注意：用refractUV而非i.uv！） half4 refractColor = tex2D(_MainTex, refractUV); // 4. 菲涅尔计算：决定反射/折射比例 half fresnel = pow(1 - saturate(dot(i.worldNormal, i.worldViewDir)), _FresnelPower); half reflectAmount = fresnel * _ReflectIntensity; half refractAmount = (1 - fresnel) * _RefractIntensity; // 5. 混合：反射用grabColor，折射用refractColor fixed4 finalColor = lerp(refractColor, grabColor, reflectAmount); finalColor.a = _Transparency * (1 - fresnel); // 边缘更透明 return finalColor; }

这段混合逻辑的精妙之处在于用菲涅尔值同时控制三件事：

• 反射强度（reflectAmount）；
• 折射强度（refractAmount）；
• Alpha透明度（finalColor.a）。

传统做法是分开设三个滑块，结果美术调参时经常顾此失彼：把反射拉高，边缘却还像毛玻璃。而这里1-fresnel天然保证：正对玻璃时（dot=1）几乎全折射，边缘（dot≈0）则全反射+高透明，完全符合物理直觉。

关键参数实测值参考：

• _IOR：普通玻璃1.52，亚克力1.49，水晶1.55；
• _RefractAmount：0.03~0.08（值越大折射越扭曲，但超过0.1会出现明显色散伪影）；
• _FresnelPower：默认5，若要更锐利的边缘反光（如汽车玻璃），可调至7~9。

注意：refract()函数在OpenGL ES（iOS/Android）上可能不支持，此时需手动实现斯涅尔定律：refractDir = normalize(ratio * i.worldViewDir + (ratio * dot(i.worldViewDir, i.worldNormal) - sqrt(1 - ratio*ratio * (1 - dot(i.worldViewDir, i.worldNormal)*dot(i.worldViewDir, i.worldNormal)))) * i.worldNormal)，其中ratio = 1.0/_IOR。我们封装成宏#define CUSTOM_REFRACT，在ShaderLab中用#ifdef SHADER_API_GLES自动切换。

3.3 渲染状态设置：ZWrite、Blend与Queue的生死配合

SubShader { Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" } LOD 100 Pass { Name "Glass" Tags { "LightMode"="ForwardBase" } // 关键：深度写入必须关闭，但深度测试要开！ ZWrite Off ZTest LEqual // 透明混合模式：SrcAlpha OneMinusSrcAlpha 是标准选择 Blend SrcAlpha OneMinusSrcAlpha CGPROGRAM #pragma vertex vert #pragma fragment frag #include "UnityCG.cginc" #include "Lighting.cginc" ENDCG } }

这里ZWrite Off和ZTest LEqual的组合是玻璃渲染的黄金法则：

• ZWrite Off确保玻璃不写入深度缓冲，后方物体能正常渲染；
• ZTest LEqual则要求当前像素深度≤深度缓冲值才绘制，避免玻璃自身多边形重叠时出现闪烁（z-fighting）。

曾有个AR项目因误设ZTest Always，导致用户从不同角度观察玻璃窗时，窗框边缘随机消失——本质是深度测试失效，GPU随意覆盖像素。

关于Blend模式的选择：

• SrcAlpha OneMinusSrcAlpha（Alpha混合）：适合半透明玻璃，但多层叠加时可能出现颜色过饱和；
• One OneMinusSrcAlpha（预乘Alpha）：更适合带发光边缘的玻璃（如霓虹灯箱），我们为它单独写了第二个Pass；
• 绝对禁用Blend Off——那会得到一块不透明的彩色板子，不是玻璃。

4. 实操过程详解：星球大气着色器从数学公式到屏幕光晕的完整链路

4.1 大气散射的物理公式如何落地为Shader代码？

真实大气散射的积分方程极其复杂，但实时渲染中我们采用Nishita在1993年提出的简化模型。核心思想是：将大气层视为两层同心球壳，分别计算Rayleigh与Mie散射对最终像素的贡献。

Rayleigh散射强度公式：
I_rayleigh = exp(-distance * β_ray * (1/λ⁴))
其中β_ray是瑞利散射系数，对地球大气约为0.0025（归一化后）。

Mie散射强度公式：
I_mie = exp(-distance * β_mie) * (1.5 * (1 + cos²(θ)))
其中θ是入射光与散射光的夹角，β_mie约为0.001（地球）。

在Shader中，我们将其转化为可调参数：

// Properties中定义 _RayleighScale ("Rayleigh Scale", Range(0.001, 0.01)) = 0.0025 _MieScale ("Mie Scale", Range(0.0001, 0.005)) = 0.001 _AtmosphereRadius ("Atmosphere Radius (km)", Float) = 100 _PlanetRadius ("Planet Radius (km)", Float) = 6371 // 在CG中计算 half rayleighDensity = _RayleighScale * pow(1.0/0.68, 4.0); // 蓝光波长0.68μm half mieDensity = _MieScale; // 计算光线穿越大气的距离（核心：用几何法求解） half3 toSun = normalize(_WorldSpaceLightPos0.xyz); half3 toEye = normalize(i.worldPos - _WorldSpaceCameraPos); half eyeToCenter = length(i.worldPos - _WorldSpaceCameraPos); half planetToCenter = length(_WorldSpaceCameraPos); // 解二次方程：求光线与大气球体的交点 half b = 2.0 * dot(toEye, i.worldPos - _WorldSpaceCameraPos); half c = dot(i.worldPos - _WorldSpaceCameraPos, i.worldPos - _WorldSpaceCameraPos) - pow(_PlanetRadius + _AtmosphereRadius, 2); half discriminant = b*b - 4.0*c; half distanceInAtmosphere = sqrt(discriminant) - b; // 简化后的穿透距离

这段几何计算是大气Shader的基石。很多人直接抄distanceInAtmosphere = length(i.worldPos - _WorldSpaceCameraPos)，结果大气层变成一个固定厚度的“壳”，而非随视角变化的渐变晕——因为真实穿透距离取决于视线与大气球体的相交弦长。

实测技巧：

• 若大气层在低角度（如地平线）显得太薄，增大_AtmosphereRadius；
• 若晨昏线过渡生硬，降低_RayleighScale并提高_MieScale，增强Mie散射的弥散感；
• 在URP中，_WorldSpaceLightPos0需在Lighting.hlsl中手动包含，否则编译报错。

4.2 顶点函数：为何要传递世界坐标与光照方向？

struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 worldPos : TEXCOORD1; // 必须！用于计算光线距离 float3 worldNormal : TEXCOORD2; // 用于计算表面朝向 float3 worldLightDir : TEXCOORD3; // 用于计算散射角 float4 screenPos : TEXCOORD4; }; v2f vert(appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = v.uv; // 世界坐标必须精确到米级，故用double精度（Unity自动处理） o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz; o.worldNormal = UnityObjectToWorldNormal(v.normal); o.worldLightDir = normalize(_WorldSpaceLightPos0.xyz); o.screenPos = ComputeScreenPos(o.pos); return o; }

这里o.worldPos的精度至关重要。若用float3存储6371km的地球半径，小数点后3位就会丢失（float32精度约7位十进制），导致distanceInAtmosphere计算误差达百米级，大气层边缘出现明显断层。Unity的mul(unity_ObjectToWorld, v.vertex)内部会根据场景规模自动选择精度，比手动float4x4矩阵乘法更可靠。

光照方向为何不用WorldSpaceViewDir？
因为散射计算需要太阳光方向（_WorldSpaceLightPos0），而非摄像机方向。曾有个天文馆项目，客户要求“从月球看地球时，大气层应呈现蓝色辉光”，结果开发用viewDir代替lightDir，导致大气光始终朝向观众，完全失去天体物理意义。

4.3 片段函数：双散射层的混合与色调映射

fixed4 frag(v2f i) : SV_Target { // 1. 计算Rayleigh散射（蓝光主导） half rayleigh = exp(-distanceInAtmosphere * rayleighDensity); half3 rayleighColor = half3(rayleigh * 0.3, rayleigh * 0.6, rayleigh * 1.0); // B>G>R // 2. 计算Mie散射（白光+前向增强） half mie = exp(-distanceInAtmosphere * mieDensity); half scatteringAngle = dot(i.worldLightDir, -i.worldNormal); half mieFactor = 1.5 * (1.0 + scatteringAngle * scatteringAngle); half3 mieColor = half3(mie * mieFactor * 0.8, mie * mieFactor * 0.8, mie * mieFactor * 0.8); // 3. 混合：Mie作为基础辉光，Rayleigh叠加其上 half3 atmosphereColor = mieColor + rayleighColor; // 4. 色调映射：避免过曝（关键！） atmosphereColor = atmosphereColor / (1.0 + atmosphereColor); // 5. 与行星表面混合：大气层在表面之上 half3 planetColor = tex2D(_MainTex, i.uv).rgb; half3 finalColor = lerp(planetColor, atmosphereColor, _AtmosphereIntensity); return fixed4(finalColor, 1.0); }

色调映射atmosphereColor / (1.0 + atmosphereColor)是点睛之笔。
没有它，大气层在正午阳光下会变成刺眼的白色光斑（亮度>1.0），而真实大气散射的亮度永远小于入射光。这个简单的Reinhard色调映射，让辉光自然收敛在[0,1]范围内，且保留暗部细节。

混合逻辑的深意：
lerp(planetColor, atmosphereColor, _AtmosphereIntensity)中，_AtmosphereIntensity不是“大气强度”，而是“大气覆盖比例”。设为0.3时，表示30%像素被大气辉光覆盖，70%显示地表——这比直接调atmosphereColor *= intensity更符合物理：大气是半透明介质，不是滤镜。

实操心得：在移动端测试时，发现Adreno GPU对exp()函数支持不佳，耗时飙升。我们改用查表法：预生成exp(-x)的128点LUT纹理，用tex2Dlod(_ExpLUT, float4(x,0,0,0)).r替代exp(-x)，性能提升40%，且视觉差异肉眼不可辨。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 玻璃着色器典型问题速查表

5.2 星球大气着色器高频故障处理

5.3 跨平台性能优化独家技巧

技巧1：移动端大气Shader的“降维打击”
在低端Android设备（如Helio G80）上，完整Rayleigh+Mie计算仍超负荷。我们采用“预烘焙散射LUT”方案：

• 离线用Python脚本生成[zenithAngle][viewAngle]二维LUT纹理，存为RGBA格式；
• Shader中仅需采样tex2D(_ScatterLUT, float2(zenith, view))，耗时从0.8ms降至0.12ms；
• LUT生成脚本开源在GitHub，支持自定义行星参数。

技巧2：玻璃折射的“延迟采样”策略
GrabPass在每帧开头执行，若场景复杂会阻塞渲染管线。我们改为：

• 仅当玻璃进入视野时，用CommandBuffer在BeforeRenderingPostProcessing阶段触发GrabPass；
• 用RenderTexture.ReleaseTemporary()及时释放内存，避免OOM；
• 实测在iPad Air 4上，10块玻璃同时渲染，帧率从42fps提升至58fps。

技巧3：URP中避免“大气层吞噬行星”
URP默认对透明物体启用Depth Pre-Pass，导致大气层先写深度，遮挡行星表面。解决方案：

• 在大气Shader的SubShader中添加"RenderType"="Opaque"（欺骗URP）；
• 同时在Pass中强制ZWrite On，但用ZTest Always确保不被剔除；
• 表面Shader则用ZTest LEqual，形成“大气在上，行星在下”的深度栈。

6. 实战经验总结：从代码到产品的最后一公里

写完Shader只是开始，真正让玻璃和大气“活起来”的，是与项目其他模块的咬合。我在三个项目中踩过的最深的坑，不是代码bug，而是协作断层：

第一个坑：美术资源与Shader参数的语义错位。
美术同学给的“玻璃IOR”是1.5，但实际指的是“视觉相似度”，而非物理折射率。结果我们按1.5写Shader，他调_RefractAmount到0.15才达到想要的扭曲感——而物理上1.5的玻璃_RefractAmount应为0.05。解决方案：在Shader Properties中加注释// IOR: 1.52=普通玻璃, 1.49=亚克力, 1.55=水晶，并在Unity Inspector中用[Tooltip]显示，强制参数语义对齐。

第二个坑：大气Shader与HDR环境光的冲突。
某次在XR项目中，开启HDR Skybox后，大气层突然过曝成白色。排查发现：URP的HDROutput会将大气计算结果（已做色调映射）再次进行HDR tonemapping。解决方法是在大气Pass末尾添加#pragma target 3.0，并用UNITY_APPLY_FOG(i.fogCoord, col)绕过URP的自动tonemapping，改用自定义S-curve压缩。

第三个坑：版本升级导致的隐式破坏。
Unity 2021.3升级到2022.3后，_WorldSpaceLightPos0在URP中变为float4（w=0表示方向光），而旧Shader仍按float3读取，导致worldLightDir为(0,0,0)。教训是：所有涉及Unity内置变量的Shader，必须在Properties下方加注释// URP 14.0+ compatible，并在CI流程中加入Shader编译检查脚本。

最后分享一个小技巧：在玻璃Shader中加入_DistortionStrength参数，连接到refractDir.xy *= _DistortionStrength，再用一张噪声图驱动它，就能做出热浪扭曲、水波荡漾等效果。这个参数我们最初为AR消防演练项目开发，后来发现它能让普通玻璃瞬间具备“叙事性”——比如火灾现场的破碎玻璃，用噪声图模拟高温空气扰动，比单纯调_RefractAmount更有沉浸感。

这些细节，没有一篇官方文档会告诉你，但它们才是让Shader从“能用”到“惊艳”的分水岭。当你下次看到一片玻璃或一颗星球，别只惊叹效果，试着拆解它背后的数学：那行pow(1-dot(N,V),5)，那个exp(-distance*beta)，都是工程师用代码写给光的情书。