Unity 5烘培场景带来的“爱”与“愁”

Unity 5烘培场景带来的“爱”与“愁”

这是侑虎科技第94篇原创文章,感谢作者雨松MOMO供稿,欢迎转发分享,未经作者授权请勿转载。
同时,作者也是U Sparkle活动参与者哦,UWA欢迎更多开发朋友加入 U Sparkle开发者计划,这个舞台有你更精彩!

作者博客:http://www.xuanyusong.com/


Ctrl+D为什么不能复制烘培效果

如果你们团队是从Unity 4版本一路用过来的,我相信你们的美术一定会说Unity 5的烘培系统太”坑爹”了。为什么呢?我们先从Unity 4的烘培聊起来。

一、Unity 4 与Unity 5的对比

Unity 4烘培场景后,如果物体不需要接收阴影,美术可以直接在Scene中用Ctrl+D进行GameObject的复制,不需要额外的再次烘培场景。为什么呢?我们随便烘培一下场景,然后用记事本一类的工具打开这个Scene如下图所示,Lightmap的烘培信息是记录在这里的。运行后Unity会根据这里的数据,把烘培信息载入给游戏对象。所以Ctrl+D复制出来的游戏对象是没有任何问题的。

请输入图片描述
或者还可以把烘培后的某个GameObject做成Prefab。Unity同样会把Lightmap的信息保存在Prefab里。用记事本一类的工具打开序列化的信息和上图是一样的。

我知道很多美术都在使用这个方法来复制游戏对象。但是这样做确实是有隐患的,当我Ctrl+D复制出来N个GameObject的时候,以后如果再次烘培这个场景,那么Scene里的Lightmap信息又会被重新刷新。

我们做一个简单的测试,如下图所示。我创建了个点光源,在Cube旁边,能看到立方体已经变成红色了。

请输入图片描述

接着,我Ctrl+D一份和它具有一样的烘培效果的Cube,移动了一下它的位置,如下图所示似乎也挺正常。
请输入图片描述

但是,此时隐患已经出现了。如果你再次烘培当前场景,此时这个物体的烘培效果已经和你当初复制的那个不一样了,因为是重新烘培,周围的光已经不同。Scene上记录的Lightmap信息也会更新,而且由于复制的物体多了烘培贴图可能也会变大。(可以确定的是和当初复制的时候肯定不一样了)

请输入图片描述
当然为了突出效果,上面的例子可能举得极端。回归实际的项目中, 通常树木、房子、石头、这些比较琐碎的东西,美术都喜欢Ctrl+D,因为相邻的物体,周围的光变化不小。所以实际上就算在烘培一下,效果也和之前差别不大。(但是烘培后,烘培贴图已经和之前的不一样了)。所以各位看官,尤其是吐槽Unity 5 烘培的美术朋友们,之前Ctrl+D的方便其实就是一个隐患。

接下来我们再来对比一下Unity 5,同样的场景我们把Scene用记事本一类的工具打开。此时已经找不到 m_LightmapIndex、 m_LightmapTilingOffset 这两个属性了,如此一来Ctrl+D是不可能复制烘培效果的。
请输入图片描述
再回到实际项目里,如果你的游戏场景比较小,烘培时间比较短,可以考虑Ctrl+D复制好以后,再统一另找时间进行烘培。但是如果你的项目场景比较大,比如有些大世界游戏,烘培一次就4个多小时,这种情况下简单复制一棵树或者一个房子还要等4个小时,显然太不科学!

二、复制烘培效果

首先我们知道场景里需要烘培的物体越多,那么对应占用的烘培贴图数量就会越多。所以解决这个问题之前,首先需要确认哪些贴图是需要复制的,哪些则不需要。需要复制的必须满足不带阴影的条件,比如 石头、草、地面的一些杂物等,不需要复制的就比较多了,总之需要产生烘培阴影的,都可以认为它不需要复制。上面说了这么多,下面再说说如何解决这个问题。

m_LightmapIndex、 m_LightmapTilingOffset 虽然不会序列化在场景或者Prefab上,但是我们可以在 Editor下或者运行时给MeshRenderer单独去赋值,或者可以做一个 Ctrl+Shift+D的快捷键来进行复制。
具体细节大家可以参考我之前写的一个例子 :https://bitbucket.org/xuanyusong/unity-duplicatelightmap

这个例子的原理就是Ctrl+Shift+D后,把当前选择的GameObject上所有的m_LightmapIndex、 m_LightmapTilingOffset取出来,克隆一份新的GameObject,然后完整地把m_LightmapIndex、 m_LightmapTilingOffset复制给新的。并且标记克隆出来的GameObject不会再参与下次的烘培,这样可以减少一些烘培贴图的数量。以后如果再次烘培,克隆出来的只会去取它克隆的那个GameObject身上的Renderer信息。

三、烘培与实时光混合使用

场景中策划希望某些物体使用实时光,而某些物体使用烘培光。比如主角使用实时光加实时阴影效果,而房子、或者山什么的都使用烘培光。如下图所示,不需要参与烘培的一定不要标记Lightmap Static 属性。(这种美术很有可能忘勾或者勾错,可以做个编辑器自动帮美术标记它)
请输入图片描述
接着标记灯光为混合模式,这样烘培后的物体就不会参与实时光的运算了。

请输入图片描述


运行时动态更新烘培贴图

很多人都反映在Unity 4上好好的,放到Unity 5上就不能在运行时更换烘培贴图了,其实Unity 5也是可以的,就是有点麻烦而已。

一、Unity 5的烘培信息

上面我们说了Unity 4的烘培信息(索引和偏移)保存在了场景或者Prefab里,然而Unity 5换地方了,如下图所示,场景烘培完后就更新这个LightingData二进制文件。(无法用记事本打开)

请输入图片描述
然而我们正常的第一反应都应该是:更换烘培贴图就是更新了这个LightingData文件。但是很遗憾的是它更新不了。Unity文档上说明,这个东西只是在Editor下用的。

二、Unity 5运行时更新

运行时更新烘培贴图分三种情况。

1、只换烘培贴图,不更换场景中的GameObject元素。
这种相对来说简单一点,通常游戏中有个白天场景,还有个夜晚场景,更新烘培贴图的时候就没必要单独做两个场景了。如下图所示,直接更换烘培贴图,直接修改LightmapSettings.Lightmaps即可。

请输入图片描述
2、需要换烘培贴图的时候,在运行中再添加GameObject元素,这种情况应该是最普遍的。
可能你是运行时Resources.Load然后Instantiate到游戏中了,这时候就要在运行时设置m_LightmapIndex、 m_LightmapTilingOffset 。比如美术的场景只做个大体框架,场景上的一些房子啊、树啊什么的是根据玩家行走的坐标动态创建出来的(走到哪里加载那些东西)。这些动态创建出来的物体是需要有烘培贴图的效果的。

对于这种需求,我建议美术单独拿出一个场景,来烘培运行时动态创建的Prefab,烘培完后工具自动绑定脚本,把对应的贴图、索引、offset都保存起来。每当这个Prefab实例化到游戏中的时候自动设置正确m_LightmapIndex、 m_LightmapTilingOffset 这两个数值即可。

3、大世界无缝地图 OpenWorld 加载烘培。
无缝大世界,就像魔兽世界那样,玩家在场景中行走,除了下副本以外,永远都不会Loading。Unity官方明确说明了,他们暂时不支持OpenWorld,但是并不是不能做。

我举个极端的例子,我们做了个N * N 的超大型场景,使用Unity自带的烘培器,烘培了100张烘培贴图。进场景以后肯定不能把这100张都载入游戏中吧?不然内存直接就挂了。理想的做法肯定是人物在世界中漫步行走,只加载附近的几张烘培贴图,释放不需要使用的烘培贴图。由于Unity没有真正的异步加载,为了避免一帧内处理的事情太多,所以尽可能地保证一帧加载的东西要少。

Renderer组件上确实是记录了Lightmap使用的序列,开始我尝试根据人物行走的坐标,取到将要出现在屏幕里或者离开屏幕里的Renderer,然后动态地加载与释放烘培贴图,保证内存里只有当前需要用的Lightmap烘培贴图。因此,在大地形的Lightmap烘焙时,大家可以尝试考虑以下方法:

  1. 如果是从零开始建立地形,那么可以直接使用Terrain Composer插件来进行制作,然后在Unity中进行烘焙,引擎会为每一块地形独自生成一个与其对应的Lightmap贴图;

  2. 如果事先已经做好地形,那么可直接在引擎中进行烘焙,烘焙后可尝试通过访问TerrainData来对地形进行切割,然后再根据地形的切分情况将其对应的Ligthmap进行切割;

  3. 对于地表物体(树、房子等模型),则可以通过Lightmap Parameters 中的 Baked Tag标签来将其进行分组,比如每块地形上的地表物体可以归结到一组,这样,这些地表物体在烘焙后,其烘焙信息会在同一张Lightmap中。
    请输入图片描述
    以上方式是针对Unity引擎的地形系统来进行烘焙,Unity的地形系统在使用上可能会带来一些Draw Call上的增加,对此,你也可以最后将Unity Terrain转换成Mesh网格来进行使用。

还有工具这块,如下图所示这样可以监听Lightmapping烘培结束后的事件。可以把对应Renderer需要烘培贴图的id、index、offset记录下来,序列化在特定的脚本中。
请输入图片描述
最后,欢迎大家给我提出宝贵的意见。也希望和大家一起探讨Unity开发技术。