［游戏引擎开发#3］隐而不现的动脉--资源管线

(又鸽了一段时间,数据太差了没动力)你有没有想过,你玩的游戏中的图片,动画,文字是怎么来的呢? 聪明的你肯定会说:"渲染啊,我直接一个大渲染下去,屏幕上就呈现了",看了标题的朋友们就知道这期我想说的不是渲染,它是一个更底层的东西--"资源管线",它是引擎的动脉为各个组分提供营养物质,将所有上层的资产转为引擎能看懂的数据,引擎再将这些数据分别给音频系统,渲染系统,输入系统等使用.

这个过程看起来很简单,实际上也确实很简单,假如我们现在有了一张图片了,如何让引擎知道这是我们项目的资产呢,在Unity中你可以通过拖拽图片来导入,这时你可以看到一个进度条,这是Unity在导入资产,细心的你会发现导入位置不仅有原始的图片,还有一个同名的.meta,那么这个.meta文件是什么?你用编辑器打开你就会发现这里面写了很多东西,它就像是一个个人信息文档,名字,身份证,物种,然后是其他相关信息,引擎拿到这份信息,就可以根据物种,分别处理.所以我们需要一个角色看门的大爷--导入器,外部人员想进去,必须得经过大爷"检查",检查好后才能进去,它只负责两件事,导入资产,重新导入资产,比如一张图片,导入器会先解析数据,然后将重要信息写入meta信息,比如长宽,格式,然后对于图片进一步,我们可以把图片直接解码为GPU压缩格式(DXT,ASTC等)减少引擎工作.

现在我们有了meta信息了,我该怎么加载,然后供给给系统呢?聪明的你肯定能想道:"简单啊,我把meta信息交给系统,让它们直接处理就行",没错这样是可行的,不过这样会让系统的维护变得很艰难,又要写导入又要写处理,就会变成一团乱麻了,当其他系统也需要使用这些资产时这就更复杂了,所以我们得抽象出一个层次出来:加载器,顾名思义,是用来加载的,它负责将导入器导入的meta信息经过处理后变成引擎内部资产,比如一张图片,引擎是无法直接渲染的,它必须要经过加载解码后压缩成GPU格式的纹理上传到GPU,这时渲染系统就可以渲染这张图片了.

这样的导入器和加载器我们只需要多创建几个,比如:字体,场景,音频等等,都可以重复上述的流程,这样我们有了新类型的资产就只需要新建加载器和导入器和处理系统就行了!万金油公式!不过呢,你肯定也看出来了弊端,加载器每次都在从meta中加载数据到内存中,如果重复加载一张图片,每次都会重新加载,这样肯定是不行的,所以我们引入第三个层次--缓存器,它就是资源管线的仓库管理员,我在加载前问一下它:"喂?你给我查查这个身份证的人是不是在厂里上班",如果在的话缓存器就回复:"老板,在的在的,这个人我马上给你带过来"然后缓存器就把人提出来,带到加载器,加载器就不需要每次都完整的重新加载,既节省了时间又省了空间,一般查询的时间复杂度只有O1!也就是说我只需要一次cpu时间就可以知道有没有加载过了(一般现代CPU的时钟为亿次/s起步),额外开销几乎为0!

我们只需要遵循上面的导入器-加载器-缓存器的结构就可以搭建一个现代化的可扩展的资源管线,而且特别建议自己写引擎时,先把资源管线写好了,而不是先去写渲染,今天说:"你看我这实现了一个超棒的渲染效果",第二天又说:"我的输入系统支持全设备!",看不见的资源管线才是最重要的,所有的脏活累活都干了,为整个引擎灌输引擎,所以你要写引擎就先写好一个优秀的资源管线.