top of page

着色器从构建里消失的那一天

作家相片: Marcel Dütscher
Marcel Dütscher
6月27日
讀畢需時 1 分鐘

在 Unity 编辑器里,一切看起来都完美。在做好的构建里:表面是粉红色的,特效也不见了。欢迎来到 Unity 最讨厌的陷阱之一——还有它的几个“亲戚”。


着色器剔除。构建时,Unity 会扔掉所有看起来用不上的东西——包括着色器。问题在于:如果你在运行时用 Shader.Find() 来加载着色器(我们就是这样加载 20 多个用于水、大气、全息影像等的自定义着色器的),Unity 在任何场景里都看不到对它们的引用。结果:着色器在编辑器里有,在构建里就没了。解决办法不起眼,却必不可少:每一个这样的着色器都必须加入图形设置里的始终包含的着色器列表。从那以后我们的规矩是:新着色器?马上加进去。


变成 -1 的那一层。类似的一类问题:我们在代码里按名称查找一个物理层。在编辑器里:能用。在构建服务器的批处理构建里:这个层不存在,查找返回 -1,所有基于这个层的东西都在悄悄地出错。从那以后,我们按固定的索引来引用层,而不是按名称。


寓意:Unity 编辑器和做好的构建是两个不同的世界。编辑器很宽容——所有素材、所有名称、所有着色器都触手可及。构建则毫不留情。所以在我们这里,对客户端的每一处改动,都要做一次真正的本地构建测试,而不是只在编辑器里按一下播放键。这样更花时间。但它还是帮我们避免了很多次尴尬的发布。

最新文章

查看全部
为什么新版本叫 2026.7.19,而不是 0.9.2 🗓️

今天更新的人,会从 0.9.1 版本一下跳到 2026.7.19。这看起来像是笔误,其实是一个刻意的决定:我们改变了版本号方案,从“语义化”版本改成了基于日期的版本(年.月.序号)。原因如下。 旧方案回答的是没人问的问题。语义化版本(0.9.1、1.2.3 ……)来自软件库的世界。在那里它很棒:第一个数字承诺“不会破坏任何东西”,第二个承诺“只有新增”,第三个承诺“只有修复”。而游戏不对任何人做这

 
 
大扫除:我们终于把 GitHub 的缓存用对了 🧹

在上一篇技术文章里,我们测量了构建和检查流水线到底花了什么:不是钱,而是等待时间和存储空间。那篇文章的结尾是“清理工作已经计划好,但还没完成”。结果比预想的快:从今天中午起,它已经进入主分支了。下面是数字。 先看结果。我们仓库的缓存用量,从 63 个条目共 5.32 GB,降到了 13 个条目共 2.46 GB。以前每个拉取请求都要跑的 C# 安全分析,现在在那里只需要 4 秒,而不是 4 分半,

 
 
每月一千次构建,而且一次都不花钱 ⚙️

先更正一件事。这篇文章的第一版声称,我们的 GitHub 构建分钟数用完了,被迫升级到 Pro 账号。这是错的,而且只要看一眼文档就能弄清楚:对公开仓库来说,GitHub 的构建分钟数是免费的。产物和缓存也一样。我们的仓库从五月底起就是公开的,所以我们从来没有为任何一分钟付过钱,以后也不会。与其悄悄改掉文字,我们宁愿重写一遍,告诉你们测量到底显示了什么。结果比错误的版本有趣得多。 先猜测,后查看。

 
 

留言


這篇文章不開放留言。請連絡網站負責人了解更多。
bottom of page