RHI即RenderHardwareInterface, 即渲染硬件接口, 是UE为实现跨平台而实现的一套API. 每个RHI接口都为OpenGL, Vulkan, DX11等做了不同的实现. 在引擎初始化时使用的绘图接口就已经确定, 引擎就可以确定RHI所使用接口的版本.

　　针对于不同的绘图API(DX11, DX12, OpenGL, Vulkan乃至于Metal), 会有不同的FRHICommandContext类对RHI方法做不同的实现(以RHIDrawIndexedPrimitive方法为例):

　　　　　　　　　　　　　　

　　作为RHI使用者, 我们不必关心具体到每种绘图API的实现差异, 只需要关注RHI这一抽象绘图接口. 可以想象在这么多绘图API中实现相似的各种效果需要多大的开发与维护成本…

　　而创建RHI对象, 不仅需要关注绘图接口, 对于不同的运行系统也会需要有不同的实现. 对于方法PlatformCreateDynamicRHI(), 也会有如下方法:

　　与想象中的不同, 并没有抽象出一套对应不同平台的接口来做RHI创建方法的不同Implementations, 而是会有这样几个全局方法.

　　看到这几个方法的时候我是懵逼的(菜是原罪…), 这么几个同名全局方法, 是怎么通过编译的, 又是怎么makefile的?

　　一顿思考之后我觉着肯定是在Build的时候排除了这几个.cpp, 之后针对不同平台#include不同的PlatformDynamicRHI.cpp来获取到对应的实现体. 创建一个新工程来测试:

　　　　　　　　　　　　　　　　　　　　　　　　

　　在AllCppTest_A/B.cpp中有全局函数char Test();的不同实现, 对应会返回a/b. 在main.cpp中:

#include "pch.h"
#define A 1
#if defined A
#define Header "AllCppTest_A.cpp"
#include Header
#else defined B
#define Header "AllCppTest_B.cpp"
#include Header
#endif
#include

int main()
{
std::cout << Test()<< std::endl;
system("pause");

}

　　选择性#include不同的.cpp文件. 这样VS在编译时会排除掉两个源文件, 而在编译main.cpp时, 宏Header会被替换为对应的Test源文件名, 对应源文件被#include, 对应的Test();函数实现会被编译.

　　上图对应的输出:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　这也就是条件式编译….

　　折腾了一晚上, RHI没看成补了节Cpp…Cpp底子还是不行啊…不禁感叹还是要多看书…整天闷头敲码不可取…