游戏引擎再出发

刚考完研究生考试,真的一言难尽,一看都会,一做感觉都做错,还漏写一道大题,感觉凉凉。为了备考,戒了快半年的C艹开发的游戏引擎。今天准备开始对这坨游戏引擎代码进行分析,重新找到当时的感觉。

目前的代码停滞在图形管线的抽象层上,当时的想法是想要弄一个RenderGraph的渲染管道(也是业界目前在研究的一种技术)。由于我想让引擎的图形操作能够达到平台无关性,也就是能在DX12和Vulkan之间切换,一来能学习一下现代图形接口的一些新思想,二来能在两者之间比较中发现是否存在bug。直到目前为止,我还没有接触过Vulkan,而是一直在DX12中摸爬滚打,现在得尝试让Vlukan加入队伍了。

打开VSCode,一看当时的代码,直接懵圈,我写了啥?

真是悔恨当初没有边推进代码的时候边写文档,这下得开始分析整个图形渲染的代码架构。当前图形代码分为两层,一层是底层图形API的封装,包括创建各种资源(如RenderTarget、TextureBuffer、VertexBuffer)以及对CommandContext操作的封装,通过抽象类的方法实现平台无关性,只需要使用我们定义好的抽象接口即可;另一层是基于前面所得的接口,分配每一帧所需要的资源、以及整个渲染管线,也就是RenderGraph。在正式渲染每一帧前,都需要构建、编译、执行RenderGraph,然后才能将得出新的一帧。整个过程如下

现在的代码能够进行简单的渲染,但RenderGraph的Compile,还没有实现,也就是对渲染图进行剪枝,因为我们的渲染图最后仅需要输出RenderTarget即可(也可以手工标记其它想要的资源),与此无关的节点也就是Pass,可以被减掉,类似于拓扑排序。这样我们就能在实际执行CommandQueue之前优化掉无关的Pass。

以上只是实际渲染的流程,当然在渲染前还有许多细节,比如说RootSignature,Shader中的资源绑定问题,在用DX12作为图形接口时,我这方面细节的设计还是比较死的,很大部分原因是目前还是基于forward rendering,而没有接触过渲染GBuffer、SSAO等管线,这些会在之后开始考虑。

说到这里,已经回想得七七八八了,那么下一步就做画线框和文本渲染的功能,方便对渲染画面进行Debug。

GAMES101 的小牛牛
GAMES101的牛牛
展示评论