UE5——UMG——分析6

实战:背包案例
1.常规做法:UMG列表控件，多个ltem子蓝图
2.很容易产生几十甚至上百个drawcal，影响性能
3.多层图片和文字，效果叠加
4.交给Slate内部布局合批，有不小CPU开销
5.通过合图集，材质内部拼接绘制可以显著减小drawcal，降低CPU开销，能解决一部分问题

解决思路:定制绘制流程，将icon和文字一次绘制，程序化绘制边框和品质背景色等信息，减少drawcal提交

下图为纯材质制作的背包UI，放入lmage中修改MID参数来使用
整个背包只有一个drawcall，解决了CPU问题


优化思路
考虑到每个ltem形式基本一致，但内容需要高度定制化，因此有两种做法:
1.拆分ltem，合并所有ltem的Mesh一起提交
2，合Instance，每个ltem一个Instance

可用自定义参数:
方案1:两个顶点色
方案2:两个顶点色[所有instance一致]+4个float[InstanceData]

从提交Buffer的大小对比，Instance方案略有优势
合Mesh方案:一个ltem的Meshltem数
合Instance方案:一个ltem的Mesh+ltem数float*4

Slate原生支持1，不支持2，这里为了演示台Instance做法
选择方案2 实际运行两个方案性能基本一致

Slate的Instance绘制

需要使用MakeCustomVerts函数自定义提交，如右图所示
参数包括顶点，索引，InstanceData等




材质中获取lnstance数据
材质内获取InstanceData方法如图所示:
InstanceData到UV2/UV3的流程如图所示:

材质中配置品质色，边框，icon等




图标和背景


优化为Instance后:指令数少了很多
即使背包数量特别大基本上也不会有性能问题
可以通过uv偏移做滑动列表，不需要额外在C++做ltem回收和复用


更多的优化
背包示例目的是讲述原理，以及刻意追求使用到前面所讲的绘图方法，因此没有进行更深入的指令优化。

实际开发中材质需要尽可能简单，指令数尽量控制在100以内，复杂逻辑也不要超过150

尽量避免0verdraw，尽量少用透明材质[迫不得已先考虑Mask材质)，下面是一些debug指令
Slate.Show0verdraw l 看Overdraw的情况
Slate.ShowBatching l 看Slate合批情况
Slate.ShowClipping l 看裁剪区情况

引擎材质大部分逻辑默认是在PS执行，但UI的顶点很少，实际需要尽可能把逻辑放到VS做
可以用VertexInterpolator节点把逻辑放在VS实现
也可以用额外的CustomUV实现
需要额外注意的是，插值器总量也有上限

其他主界面U1也可以参考类似方式实现，包括小地图/聊天窗口/血条等，每个大模块尽量只用1-2个drawcall
需要尽量把主界面Ul的drawcal控制在20以内，场景和角色/玩法就会有更多的性能发挥空间，很多3A追求的极简风UI是个不错的选择