Godot 天气与环境特效预算：下雨要有气氛，也要有帧率

天气系统最容易从氛围变成性能事故

雨、雪、雾、风沙能快速提升场景氛围，但客户端实现不好，也会快速吞掉帧率。常见问题包括：雨粒子覆盖全地图，室内还在下雨；地面积水 shader 在低端机上过重；雾效和远景裁剪冲突；天气切换时音频突兀；拍照模式下粒子穿帮；多人同步里每个客户端看到的天气不同。Godot 能做漂亮的环境特效，但天气不应该是一组美术节点随便开关，而应该是一套带预算和区域规则的系统。

这篇文章讨论客户端侧的落地：天气状态如何驱动视觉、音频和玩法，如何按设备和场景控制特效密度，如何给 QA 和美术一个可调试的预算面板。目标不是把每滴雨都物理正确，而是在玩家能感知的地方花成本，在看不见或不重要的地方降级。

天气状态要数据化

先定义 WeatherState：类型、强度、风向、湿度、能见度、雷电概率、开始时间、过渡时间。不要让场景里每个雨粒子自己决定什么时候播放。天气控制器根据状态驱动粒子、材质参数、后处理、音频和地表修饰。这样从晴天过渡到暴雨时，所有表现能按同一条曲线变化。

状态来源可以是关卡固定、任务触发、服务器同步或本地随机。无论来源如何，客户端都应把它归一化成同一个 state。对单机游戏，天气可以存档；对联机游戏，服务器下发天气种子和时间，客户端本地插值。不要每帧同步雨滴，只同步状态。

视觉预算要按层分配

天气视觉通常有几层：近景粒子、远景屏幕空间效果、地面湿润或积雪材质、天空盒和光照、后处理颜色、动态物件反应。每层都有成本。近景雨丝粒子最直观，但粒子数量和透明 overdraw 高；地面湿润 shader 能提升质感，但会增加材质变体；体积雾漂亮但移动端可能吃不消。

建议定义几个 feature level：低、中、高。低档只保留少量近景粒子、颜色调整和音频；中档增加地面湿润和远景雾；高档再加反射、闪电照明和更密粒子。WeatherController 不直接看设备型号，而是读取 GraphicsProfile 和当前帧率反馈。这样玩家手动调画质、动态缩放、平台差异都能进入同一套预算评估。

天气驱动流程

天气系统可以让 WeatherState 作为唯一输入，预算评估器决定各层表现强度：

flowchart TD
    A["WeatherState"] --> B["Visual Budget Evaluator"]
    B --> C["Particle Density"]
    B --> D["Shader Feature Level"]
    B --> E["PostProcess Intensity"]
    A --> F["Audio Ambience Layer"]
    A --> G["Gameplay Surface Modifier"]
    C --> H["Weather Renderer"]
    D --> H
    E --> H
    F --> I["Mix Bus"]
    G --> J["Movement and Footstep"]

图里有一个容易忽视的分支：Gameplay Surface Modifier。雨天可能改变脚步声、轮胎滑动、角色落地水花；雪地可能改变足迹。即使玩法不受天气影响，反馈系统也应知道地表湿润状态，否则玩家会看到大雨，却听到干地脚步。

室内外和遮蔽区域

天气最怕室内穿帮。玩家进入屋檐下，头顶还在下雨，地上却没有水；或者室内完全没有雨声，门口一步之隔突兀切换。需要在场景里放置 WeatherZone 或 OcclusionVolume，告诉系统当前位置的天气可见度。进入室内后，近景雨粒子降低或关闭，环境音切到 muffled 版本，窗外仍可保留远景雨幕。

Godot 可以用 Area3D 标记区域，角色或相机进入后切换 weather exposure。注意使用相机位置还是角色位置要按需求决定：第三人称镜头在屋外看屋内角色时，如果按相机位置，会出现角色室内却下雨；如果按角色位置，镜头屋外也没雨。一个折中是角色决定玩法和脚步，相机决定屏幕空间粒子，再由区域规则混合。

粒子和 shader 的实际策略

雨粒子不要覆盖整个世界。通常只需要围绕相机生成一个跟随体积，雨滴在相机附近循环。远处雨幕可以用屏幕空间或平面层模拟。雪花速度慢，玩家更容易看出循环，需要更大随机和深度层次。风沙则要关注方向感，与风向、镜头运动和音频一致。

地面湿润可以通过材质参数控制 roughness、darken、normal 强度，但不要在天气切换时逐个遍历全场景材质。更好的方式是用全局 shader parameter 或环境材质组。需要局部湿润的区域，例如屋檐下保持干燥，可以用顶点色、遮罩贴图或区域参数。复杂效果要配降级路径，不要让低端机也跑完整水面反射。

音频和节奏

天气音频不是一个 rain_loop 播到底。小雨、大雨、室内 muffled、雷声、风声、树叶声、水滴声都可以分层。天气强度变化时，音频层应该平滑交叉淡入。雷电要注意视觉闪光和声音延迟，远雷可以先闪后响，近雷几乎同步。音频系统还要和对白、战斗音乐的 ducking 协作，暴雨不能盖过关键提示。

在 Godot 里可以让 WeatherAudioController 管理几个 AudioStreamPlayer，按 state 和 zone 调整 bus send。不要让每个场景自己放雨声，否则切场景或进室内很容易叠音。QA 可以在调试面板上看到当前天气音频层的音量，排查“为什么这里雨声这么大”。

QA 和性能指标

天气测试要用固定场景和固定路线。记录晴天、小雨、暴雨、雪、雾在低中高画质下的帧率、GPU 时间、粒子数量、透明 overdraw、材质变体数量。Godot 的调试工具能看帧率和 draw calls，必要时用平台 profiler。不要只在空场景里测雨，真正的压力来自战斗、UI、后处理和天气同时出现。

功能用例包括：室内外切换、快速传送、拍照模式、暂停、切后台、画质切换、动态分辨率、多人同步、任务强制天气、存档恢复。还要检查天气过渡的中间状态，例如从暴雨变晴时，地面湿润是否逐渐恢复，雨声是否淡出，脚步声是否同步变化。

落地建议

第一版天气系统只做晴、雨两个状态也没关系，但要从一开始就有 WeatherState、预算评估和区域 exposure。不要把雨粒子节点散在场景里。等这条主线稳定，再增加雪、雾、雷、电光和地面积水。玩家会记住雨夜的氛围，但只有在帧率稳定、室内不穿帮、反馈一致时，这种氛围才不会变成抱怨。

天气和保存读取

如果天气影响玩法或探索体验，存档需要记录天气状态。记录当前类型、强度、随机种子、开始时间和过渡进度。读取存档后，客户端能恢复到相同天气，而不是每次进游戏都重新随机。若天气只是纯氛围，也可以只保存天气系统的时间种子，让体验大致一致。

任务强制天气要有优先级。普通世界天气是 base layer，任务或剧情可以推一个 override，室内区域再乘 exposure。不要让三个系统互相直接改粒子节点。WeatherState 可以由 stack 合成：世界晴天，任务暴雨 override，室内 exposure 0.2，最终屏幕雨强 0.2、音频 muffled、地面湿润按室内规则处理。

闪电和安全性

闪电效果很容易做过头。强白闪可能影响视觉舒适，尤其是频繁雷暴。建议提供闪光强度上限和无障碍选项，允许降低频闪。闪电照亮场景可以通过 DirectionalLight 或环境参数短暂变化，但不要每次创建销毁灯光节点，使用预置节点调整能减少尖峰。

雷声随机也要控制。完全随机可能连续三次近雷，玩家烦躁；可以用最小间隔、强度曲线和距离模拟。闪电视觉和声音之间的延迟按距离计算，远雷更有空间感。开发包显示下一次雷电计时和强度，方便美术调节。

与地表反馈系统衔接

前一类系统如果已经有 SurfaceProfile，天气可以修改 surface 状态：干地、湿地、积雪、泥泞。脚步声、粒子、水花、轮胎痕迹都读取同一状态。不要让天气系统单独播放脚步水声，否则和角色移动材质脱节。

地表状态还可以有滞后。雨停后地面不会立刻变干，阳光区域干得快，阴影区域慢。客户端不一定要模拟真实水分，但可以用区域参数做简单过渡。这样雨后世界更可信。性能不足时，只保留音频和颜色变化，也比完全瞬间切回晴天自然。

内容制作规范

天气资源需要命名和预算规范。每种天气有一个 profile，列出粒子材质、最大粒子数、shader feature、音频层、适用平台。美术新增暴雪效果时，必须填写低中高三个档位。程序可以写检查工具，发现 profile 缺低档资源或粒子上限过高就报警。

这不是限制美术，而是避免上线前才发现某个天气只在高端 PC 上好看。天气是全局效果，坏一次影响整张地图。预算前置，创作反而更自由，因为大家知道边界在哪里。

低端设备的降级不是简单关闭

直接关闭天气会让世界割裂。低端设备可以保留低成本信号：天空颜色、环境音、少量屏幕空间雨线、地表脚步变化。关闭昂贵的反射、体积雾和高密度粒子。玩家仍能理解“正在下雨”，只是少一些细节。降级要保持语义，不只是砍效果。

动态降级也要平滑。帧率掉到阈值以下时，不要瞬间让雨消失。可以先降低粒子发射率，再降低远景雾，再关闭反射。恢复时反向逐步打开，并设置冷却时间，避免帧率在阈值附近导致效果闪烁。预算评估器要有滞后。

天气和截图、拍照模式

拍照模式通常希望天气更好看，但也不能改变真实世界。可以在拍照模式临时提高视觉层质量，例如增加近景粒子或开启更高后处理，但不改变 gameplay surface 和存档天气。退出拍照后恢复。若玩家在低端设备上拍照，仍要受平台上限约束，不能为了截图把游戏卡死。

截图分享还要注意隐私和清晰度。强雨和雾可能遮挡 UI 或二维码类分享元素，拍照模式可以提供天气强度滑杆，但这只是本地表现，不提交到世界状态。功能边界写清楚，玩家不会以为自己能改变服务器天气。

编辑器预览工具

给美术一个 Weather Preview 面板非常有用。选择天气类型、强度、画质档、区域 exposure，实时看到粒子数、shader feature、音频层。还可以一键在当前场景中播放晴到雨、雨到雪的过渡。没有预览工具时，美术只能进游戏跑流程，迭代很慢。

预览工具还可以检查 profile 完整性：是否缺低档粒子，是否引用不存在的音频，是否某个 shader 参数没有绑定，是否最大粒子数超过平台建议。天气系统跨资源很多，工具化能减少提交破坏。

多人一致性

联机游戏中，天气若影响能见度或脚步声，必须由服务器权威同步。客户端可以本地插值，但不能自己随机暴雨。若天气只是大厅氛围，可以允许本地差异。设计上要明确，否则玩家 A 看见浓雾，玩家 B 看见晴天，战斗公平性会出问题。

服务器下发天气状态时，客户端不要硬切。按 server time 计算当前过渡进度，落后加入的玩家也能看到同一阶段。重连后用权威状态覆盖本地缓存，视觉上平滑修正。

和存量场景的迁移

如果项目已经在很多场景里手动摆了雨、雾、风声节点，不必一次性全删。可以先让 WeatherController 接管新场景，同时写一个兼容适配器，把旧节点注册成天气层。适配器只做开关和强度映射，不再让旧节点自己决定状态。等场景迭代时逐步替换成 profile。

迁移期间要防止双重播放。开发包可以扫描场景里未注册的 Weather 粒子或雨声音频，提示“该节点不受天气系统控制”。否则同一场景可能既有旧雨声又有新雨声，问题听起来像混音错误，实际是控制权重复。

和玩法判定保持距离

天气可以影响体验，但客户端不要擅自改变权威玩法判定。比如雨天降低视野、风雪影响弹道、泥地降低速度，如果这些会影响胜负，就必须由服务端或单机权威逻辑统一计算。视觉层可以提前表现湿滑和能见度，但实际数值来源要明确。否则联机中不同画质、不同设备看到的天气强度不同，会导致公平性问题。

一个稳妥做法是把天气拆成 visual_intensity 和 gameplay_intensity。视觉强度可以按设备降级，玩法强度必须跟权威状态一致。低端机可以少画雨，但角色仍按同样的湿地规则移动。这样既保护性能，也不改变规则。