本文是腾讯的一篇H5 跨引擎解决方案的精炼。
介绍
本文通过实现基于精简版的HTML5(HyperText Mark Language 5)来屏蔽不同引擎,平台底层的差异。 好处: 采用H5的开发方式,可以将开发和运营分离,运营部门自主开发的运营活动不依赖于游戏发版本的节奏。
如需要开发游戏周边系统会遇到如下4个问题:
1 每个游戏使用不同引擎时,周边系统是否可以不考虑引擎差异
2 每个游戏都有自己的开发版本的节奏。运营开发是否可以不跟随。
3 不同游戏, 不同引擎 不同平台 开发方式是否可以保持一致
4 这套开发方式 是否可以和游戏引擎开发的系统在交互 操作 性能保持一致。
一个想法是在游戏内嵌入 WebView, 然而这种方式对于 4 这种方案不会支持。为了解决 4 这种方案,腾讯推出了新的解决方案。
H5 ES 标准提出(HTML 5 Embeded System)
精简的H5有如下能力
HTML CSS JS 代码的解析能力
核心标签的支持, 包括DIv, Script, Style, Img, Text.
核心DOM API 支持,事件机制
背景 边框 图片(GIF动图) 文本渲染
FlexBox
CSS Animation, Transform
视频播放,直播
WebSocket XMLHttpRequest 支持Wss Https。
为了实现上面提到的基元操作,可以考虑吧对应的操作抽象为一系列的接口,宿主程序实现对应的接口就可以完成对于的操作。有如下2中抽象模式
完全自己渲染
抽象为接口,要求宿主对应的实现
如果是完全自己渲染,则1需要考虑不同平台和图形系统,做法和游戏引擎自身实现的跨平台抽象是一致的。一般做法是抽象为RHI,RHI分装了 OpenGL Vulkan DirectX 等图形API,通过使用这样的抽象的APi来实现上层的UI渲染,吧UI渲染到RenderTarget,在不同引擎渲染RenderTarget,这样就可以实现不同引擎内跨平台的渲染一致的UI。
这样的作法有几个问题:
问题一: RHI的封装
要实现RHI,其实有很多问题。例如如何实现RHI, RHI需要多大Code Size, 如何保证RHI封装不会和其他的RHI引擎冲突。
首先我们使用的是GitHub上的一个开源的bgfx,它实现了对所有API封装,非常聚焦。
bgfx总共2.2MB代码段同时提供了 bimg和bx2个库,用于图形解码和函数基础库,这正好做UI必备。
修改bgfx的创建设备流程,使他可以接受一个外部图形API运行时的指针。还需要修改一些Clear, Present等流程。让bgfx在RenderTarget上工作。
用bgfx来桥接的话,(会有问题)会不会对引擎RHI状态侵入?例如,引擎自身的RHI通过逻辑而不是查询硬件状态记录了RenderState,那么bgfx跳过了RHI进行渲染,会不会破坏渲染状态?
问题二: 额外的RenderTarget负担
将UI渲染到贴图是需要额外的RenderTarget内存开销,这部分开销随渲染的UI的尺寸不同而不同。如果1024 * 768像素渲染一个整屏的UI,那么将需要 3MB 的内存, 目前主流手机分辨率一般都在2K以上,那么这部分内存可能超过10MB,这无论如何都无法接受。
如果不使用RenderTarget会怎么样?如果不使用RenderTarget,可以考虑的方案是吧UI直接渲染到BackBuffer上,一般在Present之前,就将UI覆盖在引擎所有画面之上,包括引擎自身的UI。
这种问题无法控制UI与现有的游戏引擎UI的层级关系,也无法让他嵌入现有的UI系统里协同工作,只能硬生生的覆盖在上面,这在实际的工作中是无法接受的。为此只能使用RenderTarget,从而避免UI层级和UI协同的问题,因为通过RenderTarget可以把UI渲染到任何现有UI层级之上,甚至渲染到3D场景中。
问题三: 抽象为接口问题
如果将绘制能力抽象为少数接口,并由宿主来完成,就不需要实现整套的RHI解决方案,这样能
减少运行时的代码段,不需要RenderTarget,减小运行时内存,还能灵活运用现有引擎的UI交互能力,不会出现层级问题,
在这里有3种思路, 如下:
* 抽象为RHI,要求宿主实现RHI
*抽象为对象接口,要求宿主实现图元对象
*抽象为图元绘制接口,要求宿主实现图元绘制能力
抽象RHI的代码如下:
class RHI
{
public:virtual VertexBuffer* CreateVertexBuffer(...) = 0;virtual Texture* CreateTexture(...) = 0;...
};
基本想法就是要求宿主实现RHI,基于这些RHI完成绘制,并将最终的渲染指令流转到引擎的渲染管线。这个想法简单直接,非常易于集成,如果单独考虑Unreal Engine,那么基本上使用这种抽象就可以了。这种抽象形式时Unity引擎里不太容易控制,虽然Unity 提供了Low LevelPlugin 系统,但这套系统尚不完善,没有完成RHI的封装,需要自己制作,而且Low Level Plugin结果很难控制,无法和Unity本身的UI系统很好的结合。在Unity 5 之后,Unity引入一套Command Buffer系统,这套系统也可以完成自定义渲染,但问题是和Low LevelPlugin类似。
抽象为对象接口的代码如下:
class IH5Host
{public:Text* createText(...);Image* createImage(...);Border* createBorder(...);
}
这样抽象适合于Unity系统,可以把基本图元转换为·Unity系统里的Text,Image对象。这样抽象后会产生对象管理问题(生命周期, 对象控制),会产生不一致。
一种折中方案时根据DOM对象树来建立一颗渲染树,2边基于渲染树来渲染。
抽象为图元绘制接口:
class IH5Render
{public:void paintText(...);void paintImage(...); void paintBackGround(...);void paintBorder(...);
}
图元绘制接口和对象接口的差别是,图元绘制接口每帧都有需要调用,无状态,而对象接口构造调用一次,析构调用一次,有状态,需要自行管理生命周期。UE4就采用了我图元绘制接口,在FSlateDrawElement类种,抽象为图元绘制接口如下
class FSlateElement
{SLATECORE_API static void MakeBox( FSlateWindowElementList& ElementList,uint32 InLayer,const FPaintGeometry& PaintGeometry,const FSlateBrush* InBrush,ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None,const FLinearColor& InTint = FLinearColor::White );UE_DEPRECATED(4.20, "Storing and passing in a FSlateResourceHandle to MakeBox is no longer necessary.")SLATECORE_API static void MakeBox(FSlateWindowElementList& ElementList,uint32 InLayer, const FPaintGeometry& PaintGeometry, const FSlateBrush* InBrush, const FSlateResourceHandle& InRenderingHandle, ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None, const FLinearColor& InTint = FLinearColor::White );SLATECORE_API static void MakeRotatedBox(FSlateWindowElementList& ElementList,uint32 InLayer, const FPaintGeometry& PaintGeometry, const FSlateBrush* InBrush, ESlateDrawEffect,float Angle,TOptional<FVector2d> InRotationPoint,ERotationSpace RotationSpace = RelativeToElement,const FLinearColor& InTint = FLinearColor::White );SLATECORE_API static void MakeRotatedBox(FSlateWindowElementList& ElementList,uint32 InLayer,const FPaintGeometry& PaintGeometry,const FSlateBrush* InBrush,ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None,float Angle = 0.0f,TOptional<FVector2f> InRotationPoint = TOptional<FVector2f>(),ERotationSpace RotationSpace = RelativeToElement,const FLinearColor& InTint = FLinearColor::White);........
}
这个类时图元绘制接口,UE4中的空间都是基于这个类提供的方法来绘制UI元素的,同时会根据绘制的调用顺序来考虑合批操作(Batch),这样调用的接口就自动具备了合批能力。
考虑到不同引擎的实现复杂度,包括在·自研引擎这种没有很好的对象体系来说明的引擎中容易集成,最终的做法是抽象为图元绘制接口。在UE4中可以无缝衔接,在Unity有点麻烦。
我们吧H5 ES页面的解析,加载,排版,渲染抽象等接口统称为UI前端,把不同引擎实现的渲染接口统称为后端,如图
渲染后端的实现
讨论完了架构,下面介绍如何在当前主流的2个商业引擎和自研引擎上具体实现相关功能。
UE4
UE4引擎提供Plugin机制,能够轻松将扩展功能放入Plugin插件中,基于Plugin的模式可以很好的实现UE4后端渲染。作为UE4扩展UI的组件需要遵循以下3个原则:
1 去除引擎定制化功能,版本需要通用。
2 符合UE4的UI通用风格。
3 保持渲染效率和性能一致性。
通过参考UE4的Slate UI的实现方式,在满足以上3个原则的同时可以自定义封装一个UMG的UI控件,用户可以在编辑蓝图的可视化时使用,并在蓝图中调用相关的接口功能。
1 UE4的渲染实现
继承UWidget(UMG基类)和SWidget(SlateUI基类)这2个基类,并实现自定义Custom UI组件。
FSlateDrawElement::MakeText // 绘制字体
FSlateDrawElement::MakeLines // 绘制线条
FSlateDrawElement::MakeBox // 绘制图片 矩形
2 UE4的资源管理
核心的资源管理通过句柄来关联,资源的生命周期通过引用计数来控制,目前用到的句柄分为一下3种。
绘制上下文:此外指临时上下文,由绘制方自行管理,H5的内核绘制·只进行上下文透传处理。
贴图资源:贴图绘制的资源对象
字体资源:文字绘制的资源对象
H5的内核通过句柄对象的引用计数来管理对应句柄的生命周期。例如,打开动态页面A使用font和image就会通过资源管理器获取是否存在,存在引用就会加加,如果则调用对应的创建接口来通知引擎需要创建资源,引擎通过创建返回句柄值。
绘制上下文是一个临时句柄对象,内核不需要创建此对象,并且使用比较简单。在UE4中由SWidget::OnPaint发起绘制时,调用H5::Paint(HANDLE device)就可以指定device对象对应绘制就会将此参数作为绘制参数传回。。如H5::DrawText(HANDLE device, ..);
资源使用如下:
贴图资源,(字体资源也一样)在UE4中,UTexture2D时用来管理贴图资源对象。当H5内核驱动来创建对象的时候,UE4端会将UTexture2D地址值最为参数传回给H5内核。将此贴图对象加入一个内核管理列表,通过H5的抽象绘制接口(DrawImage)将句柄信息关联到对应的UTexture2D对象,然后提供给FSlateDrawElement::DrawBox的渲染接口使用。
句柄销毁如下
如果关闭了页面,那么对对象的引用就会减1,如果引用计数为01就会销毁句柄,并通知UE4销毁资源。
3 UE4的特殊绘制
在H5中实际使用会用到一些特殊的图元,例如圆角头像,圆角边框等。在UE4中原始图元接口并不能直接支持,我们需要使用Shader才能高效实现。FSlateBrush支持Shader画刷, FSlateMaterialBrush数据FSlateBrush的派生类,可以通过Shader方式来特殊绘制。(实现细节可以查看 腾讯游戏开发精粹2 P254-257 )
4 UE4版本差异引发问题
接口变更可以根据不同宏去替换对应功能,以下是重点特例问题:
问题1: FSlateBrsuh绘制参数的保持问题。
UE4 4.21之前版本使用FSlateBrush画刷绘制时,FSlateDrawElement并未保存画刷中的一些参数问题(Margin, Tiling, Mirror, UVRegion, DrawAs),支持有FSlateBrush本身的指针地址,这样会带来2个问题。
• FSlateBrush 安全性不能保证,因为游戏线程和渲染线程时不同的线程。
• 相同的FSlateBrush不能使用在不同绘制参数上多次绘制。例如同一张贴图画刷 先绘制一张UVRegion从(0,0)到(1,1)的全图,在绘制一张 UVRegion(0.5,0.5)到(1,1)的半图,结果绘制了2张半图,因为在FSlateBrsh投递渲染指令到渲染队列的时候是以FSlateBrush指针的方式获取当前渲染指令的绘制参数的,所以相同的渲染队列里的相同FSlateBrush指针的渲染参数时相同的。
解决方案:
• 在FSlateDrawElement中保存渲染参数并在提交渲染指令的时候使用FSlateDrawElement保持的渲染参数,(在UE4.21以后的版本修复了 FSlateDrawElement 使用DataPayload拷贝FSlateBrush绘制参数) 。
• 当同一个FSlateBrush进行不同的渲染参数绘制时,使用新的FSlateBrush进行绘制;基本的方式是使用引用队列存储不同的绘制参数的FSlateBrush,并在绘制完成后Check FSlateBrsh引用情况,对于没有引用的进行安全的延迟释放。
问题2:Slate UI的合批问题:
UE4.24之后的版本使用了新的合批算法,在进行文字合批的时候,遇到空格单字符 FSlateDrawElement不会计算字符绘制的顶点数和边数,而会把FSlateDrawElement当成一个未合批的缓存节点,如果最后一个绘制元素是字符空格,则此合批缓存节点的顶点偏移值恰好是缓存顶点队列的大小的值。在进行缓存节点合批时,不会判断需要合批节点是否是有效的值的顶点数,这样在合批的时候就会出现数组越界的情况,引发程序的Crash。
解决方案:
• 修改源代码,将绘制顶点数为0的节点不进行合批操作。
• Plugin插件,使用H5页面绘制遇到空格单字符跳过绘制。
UE3
UE3不像UE4有系统UI管理模块,需要自己管理。所以采样动态库加载的方式(减少与引擎代码耦合度和资源管理) UE3绘制UI通过Canvas来绘制,因此我们需要自定义一类Canvas来管理,
Unity
UE4绘制接口可以称为 Immediate Mode接口,Unity UI系统提供了Immediate Mode接口的GUI系统,,由于效率,此系统只使用在编辑器模式下,在游戏环境中,使用UGUI,这样需要考虑将创建对象的接口转换为Immediate mode接口,同时也要考虑 C#和C++交互。
1 C++和C#通信
C#调用C++ 通过使用C++动态库导出方法符号在C#使用DllImport 指定导入的方法名称。
2 Unity3D渲染
Unity3D提供Low Level Plugin机制来扩展渲染,这套机制在早期由许多Bug所以不能很好的结合。
3 Unity3D和H5渲染结合
在Unity3D中,H5的渲染接口要对应RHI更上层机制,要按照下图方式来渲染。(渲染Box模型的基础图元)
• 背景
• 边框
• 图片
• 文字
因为使用的时Immediate mode模式接口来实现封装渲染指令,每一帧都要发送的话,太费了,所以我们使用渲染队列
4 接口转换
Unity3D提供了UI框架UGUI,渲染文本UGUI提供了渲染组件Text,Text基本满足大部分的渲染需求,当收到H5的渲染指令的同时,先根据渲染指令类型,创建对应的UGUI组件,然后渲染指令的信息应用到组件上。
5 渲染基本图形
除了图片文字等可以直接通过接口转换,还有一些接口,无法在UGUI找到合适的组件,如渲染线段,虚线,边框等,在这里我们使用UGUI中的渲染矢量图形,MaskableGraphics这个类型支持直接修改顶点信息功能,
6 控制信息
Unity3D通过使用Mask组件来控制一些空间是否显示。
7 性能优化
方案 :
• 预先创建若干个组件。
• 连接对应组件使用hash
• 运算压力大的异步执行
• 缓存预算结果
自研引擎
1 Present/Swap钩子
通过使用函数拦截可以在完成一帧渲染的同时执行额外的绘制指令,从而显示H5 UI
优点:
宿主无感知
没有额外的显存消耗
缺点:
产出无中间态,永远覆盖在最上层。无法融入宿主UI
2 使用Render Target
RenderTarget本质时一个离屏输出区域,使用RenderTarget,宿主可以自由i的操作多个嵌入式窗口实例,并对其结构进行灵活组装,以实现各种复杂的融合效果。
3 使用RHI在包装
我们使用了bgfx的第三方渲染库来实现自研引擎扩展H5。方式类似于(UE)具体详见 腾讯游戏开发精粹2 P267-269
网络库
标准H5由2大网络设施,XmlHttpRequest和WebSocket前者解决单次调用问题,后者解决服务器推送问题,这2者本质都是HTTP,需要良好的封装,社区有大量有封装好的开源库例如libcurl/libwebsocket.但是作为一个嵌入式引擎,为减少代码体积,成为关注问题。
总结
在·介绍H5 UI设计抽象的IH5Render接口,在2大流行的商业引擎和自研引擎实现方式,对比3种方式的异同。
• 在商业引擎中,我们关注如何找到商业引擎自带的绘制功能去表现H5的UI绘制单元,在自研引擎模式下,我们重做了一边商业引擎的路。
• 同为商业引擎,在Unity3D和UE4也有很大的差别,UE4提供的接口更偏向于底层,而Unity3D中的接口更偏向于中层,基本上是通过生成场景图的节点加功能组件来承接IH5Render的输出。