深圳建设局官网站首页,大数据营销精准营销,东莞网络营销推广公司,网站群维护方案本文是腾讯的一篇H5 跨引擎解决方案的精炼。
介绍
本文通过实现基于精简版的HTML5#xff08;HyperText Mark Language 5#xff09;来屏蔽不同引擎#xff0c;平台底层的差异。 好处#xff1a; 采用H5的开发方式#xff0c;可以将开发和运营分离#xff0c;运营部门自…本文是腾讯的一篇H5 跨引擎解决方案的精炼。
介绍
本文通过实现基于精简版的HTML5HyperText 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需要考虑不同平台和图形系统做法和游戏引擎自身实现的跨平台抽象是一致的。一般做法是抽象为RHIRHI分装了 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系统里的TextImage对象。这样抽象后会产生对象管理问题生命周期 对象控制会产生不一致。
一种折中方案时根据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,TOptionalFVector2d 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,TOptionalFVector2f InRotationPoint TOptionalFVector2f(),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的渲染实现 继承UWidgetUMG基类和SWidgetSlateUI基类这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从00到11的全图在绘制一张 UVRegion0.50.5到11的半图结果绘制了2张半图因为在FSlateBrsh投递渲染指令到渲染队列的时候是以FSlateBrush指针的方式获取当前渲染指令的绘制参数的所以相同的渲染队列里的相同FSlateBrush指针的渲染参数时相同的。
解决方案 • 在FSlateDrawElement中保存渲染参数并在提交渲染指令的时候使用FSlateDrawElement保持的渲染参数在UE4.21以后的版本修复了 FSlateDrawElement 使用DataPayload拷贝FSlateBrush绘制参数 。 • 当同一个FSlateBrush进行不同的渲染参数绘制时使用新的FSlateBrush进行绘制基本的方式是使用引用队列存储不同的绘制参数的FSlateBrush并在绘制完成后Check FSlateBrsh引用情况对于没有引用的进行安全的延迟释放。 问题2Slate 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提供了渲染组件TextText基本满足大部分的渲染需求当收到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的输出。
