CN110609726A

CN110609726A - 贴图处理方法及装置、计算机可读存储介质、电子设备

Info

Publication number: CN110609726A
Application number: CN201910871816.4A
Authority: CN
Inventors: 潘乐乐; 李青; 任帅
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2019-09-16
Filing date: 2019-09-16
Publication date: 2019-12-24
Anticipated expiration: 2039-09-16
Also published as: CN110609726B

Abstract

本发明实施例是关于一种贴图处理方法及装置、计算机可读存储介质、电子设备，涉及图像处理技术领域，该方法包括：将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图；对各所述页面贴图进行压缩得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图；将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域；根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。本发明实施例降低内存的占用率同时提高了贴图的虚拟贴图的利用率。

Description

贴图处理方法及装置、计算机可读存储介质、电子设备

技术领域

本发明实施例涉及图像处理技术领域，具体而言，涉及一种贴图处理方法、贴图处理装置、计算机可读存储介质以及电子设备。

背景技术

随着手机游戏的普及，游戏也需要更多的考虑在移动设备上的内存问题，尤其是针对于某些品牌的1G RAM设备，在内存使用量达到500M左右就大概率会crash(崩溃)。其中，贴图内存在游戏中占了很大的比重，随着游戏的迭代和项目的开发，UI(UserInterface，用户界面)界面所使用的贴图数量会越来越多，一般游戏UI贴图的总量在项目后期会达到20张2048*2048尺寸的大图，即使考虑压缩和部分加载的情况，运行时也普遍会占用60M以上的内存。因此，UI的贴图管理不管对性能还是内存，都有重要的作用。

在现有的UI贴图管理方法中，主要包括以下几种：一种是，使用散图，每个UI的渲染节点都单独加载属于自己的UI贴图，不同节点的UI贴图独立保存；另一种是，将多个散图离线合并成大图，比如将多张散图合并成一张2048*2048的大图，然后压缩成对应平台支持的GPU纹理格式，如ETC格式、PVR格式或者ASTC格式等等。

但是上述UI贴图管理方法存在如下缺陷：在第一种方法中，如果不对散图进行压缩，则会占用较多内存；如果压缩，由于很多GPU压缩纹理要求POT(长宽是2的幂次方)，使得要将贴图尺寸扩展到POT，会降低贴图空间利用率；并且，这种方式会导致每个渲染节点都使用了不同的贴图纹理，不同贴图的UI节点无法进行合批渲染；

在第二种方法中，如果不同UI节点所使用到的贴图正好在同一张大图中时，就存在合批的可能，降低UI的渲染批次，提高性能；但由于离线完成的纹理合并，很可能运行时显示的UI界面包含了很多张大图，而真正界面用到的图片只占了大图的很小一部分，这不仅浪费了贴图内存，而且降低了合批效率。

因此，需要提供一种新的贴图处理方法及装置。

需要说明的是，在上述背景技术部分发明的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明的目的在于提供一种贴图处理方法、贴图处理装置、计算机可读存储介质以及电子设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的内存占用较多以及贴图空间利用率较低的问题。

根据本公开的一个方面，提供一种贴图处理方法，包括：

将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图；

对各所述页面贴图进行压缩得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图；

将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域；

根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。

在本公开的一种示例性实施例中，在将所述待处理贴图对应的压缩纹理数据上传至相应的所述贴图区域之后，所述贴图处理方法还包括：

对所述贴图区域中具有相同渲染状态的各待处理贴图对应的压缩纹理数据进行合批，并对合批后的待处理贴图进行渲染。

在本公开的一种示例性实施例中，根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域包括：

根据所述待处理贴图在所述虚拟贴图中的位置以及大小，从所述虚拟贴图中加载出与所述待处理贴图对应的一个或者多个页面贴图；

将与所述一个或者多个页面贴图对应的所述压缩纹理数据上传至所述一个或者多个贴图区域。

在本公开的一种示例性实施例中，在将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域之后，所述贴图处理方法还包括：

对各所述贴图区域的当前状态进行记录；其中，所述当前状态包括空闲状态或者占用状态；

其中，将与所述一个或者多个页面贴图对应的所述压缩纹理数据上传至所述一个或者多个贴图区域包括：

将与所述一个或者多个页面贴图对应的所述压缩纹理数据上传至所述一个或者多个处于空闲状态的贴图区域。

在本公开的一种示例性实施例中，所述虚拟贴图中的两个相邻的所述待处理贴图之间间隔有预设像素；

两个相邻的所述页面贴图之间具有预设数量的重叠像素，所述重叠像素的颜色值为所述页面贴图对应的待处理贴图的相邻颜色值。

在本公开的一种示例性实施例中，在对合批后的待处理贴图进行渲染之前，所述贴图处理方法还包括：

对所述待处理贴图的顶点数据进行转换；和/或

对所述待处理贴图的UV数据进行转换。

在本公开的一种示例性实施例中，对所述待处理贴图的顶点数据进行转换包括：

根据所述待处理贴图对应的页面贴图的网格，利用矩形将所述待处理贴图渲染至二维平面，完成对所述待处理贴图的顶点数据的转换。

在本公开的一种示例性实施例中，对所述待处理贴图的UV数据进行转换包括：

配置标签贴图；其中，所述标签贴图的像素与所述页面贴图的像素一一对应；

将所述页面贴图在所述物理贴图中的页面偏移的UV信息保存至所述标签贴图中；

根据所述待处理贴图在所述页面贴图中的UV坐标以及所述UV信息，得到所述待处理贴图对应的页面贴图在所述物理贴图中的UV坐标。

在本公开的一种示例性实施例中，所述虚拟贴图的像素为64K*64K；

所述物理贴图的像素为4096*4096；

所述页面贴图的像素为128*128。

根据本公开的一个方面，提供一种贴图处理装置，包括：

虚拟贴图切分模块，用于将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图；

物理贴图创建模块，用于对各所述页面贴图进行压缩，得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图；

物理贴图划分模块，用于将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域；

数据上传模块，用于根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。

根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的贴图处理方法。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的贴图处理方法。

本发明实施例一种贴图处理方法及装置，一方面，通过将待处理贴图离线合并至具有虚拟贴图中，并对虚拟贴图进行切分得到多个尺寸相同的页面贴图；然后对各页面贴图进行压缩得到与各页面贴图对应的压缩纹理数据，并根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域，解决了现有技术中不对散图进行压缩导致内存占用较多以及需要对贴图的尺寸进行扩展导致贴图空间利用率的问题，降低内存的占用率同时提高了贴图的虚拟贴图的利用率；另一方面，对各页面贴图进行压缩得到与各页面贴图对应的压缩纹理数据，并根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据待处理贴图在虚拟贴图中的位置，将待处理贴图对应的所述页面贴图的压缩纹理数据上传至贴图区域，解决了现有技术中由于离线完成的纹理合并，很可能运行时显示的UI界面包含了很多张大图，而真正界面用到的图片只占了大图的很小一部分，这不仅浪费了贴图内存，而且降低了合批效率的问题，提升了合批效率并且降低了资源浪费；再一方面，通过根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据待处理贴图在所述虚拟贴图中的位置，将待处理贴图对应的页面贴图的压缩纹理数据上传至贴图区域，使得可以对相同渲染状态的待处理贴图对应的压缩纹理数据进行合批，减少了渲染批次，进而提高了渲染速度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出根据本公开示例实施例的一种贴图处理方法的流程图。

图2示意性示出根据本公开示例实施例的一种根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域的方法流程图。

图3示意性示出根据本公开示例实施例的一种对所述待处理贴图的顶点数据进行转换的应用场景示例图。

图4示意性示出根据本公开示例实施例的一种对所述待处理贴图的UV数据进行转换的方法流程图。

图5示意性示出根据本公开示例实施例的一种对所述待处理贴图的UV数据进行转换的应用场景示例图。

图6示意性示出根据本公开示例实施例的一种字体贴图的实时压缩方法的流程图。

图7示意性示出根据本公开示例实施例的一种贴图处理装置的框图。

图8示意性示出根据本公开示例实施例的一种用于实现上述贴图处理方法的电子设备。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本发明的各方面变得模糊。

此外，附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

调用一次渲染API(Application Programming Interface，应用程序编程接口)的绘制接口(Direct3D的DrawPrimitive/Draw IndexedPrimitive，或者OpenGL的glDrawArrays/glDraw Elements)来向GPU提交使用相同渲染状态的一定数量的三角形的行为为一个渲染批次。一个渲染批次需要进行的顶点传输，渲染状态切换，shader(着色)设置，绘制请求都是比较耗时的操作，因此渲染批次的多少严重影响着游戏的运行效率。对于UI的绘制，除去少部分有裁切效果或者特殊shader实现效果的UI节点以外，大部分UI节点所使用的shader和渲染状态都基本一致，而顶点可以采用统一的格式在CPU端进行合并，所以贴图的大小以及数据格式是否一致在很大程度上决定了UI的合批效果。

本示例实施方式中首先提供了一种贴图处理方法，该方法可以运行于服务器、服务器集群或云服务器等；当然，本领域技术人员也可以根据需求在其他平台运行本发明的方法，本示例性实施例中对此不做特殊限定。参考图1所示，该贴图处理方法可以包括以下步骤：

步骤S110.将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图。

步骤S120.对各所述页面贴图进行压缩得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图。

步骤S130.将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域。

步骤S140.根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域

上述贴图处理方法中，一方面，通过将待处理贴图离线合并至具有虚拟贴图中，并对虚拟贴图进行切分得到多个尺寸相同的页面贴图；然后对各页面贴图进行压缩得到与各页面贴图对应的压缩纹理数据，并根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域，解决了现有技术中不对散图进行压缩导致内存占用较多以及需要对贴图的尺寸进行扩展导致贴图空间利用率的问题，降低内存的占用率同时提高了贴图的虚拟贴图的利用率；另一方面，对各页面贴图进行压缩得到与各页面贴图对应的压缩纹理数据，并根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据待处理贴图在虚拟贴图中的位置，将待处理贴图对应的所述页面贴图的压缩纹理数据上传至贴图区域，解决了现有技术中由于离线完成的纹理合并，很可能运行时显示的UI界面包含了很多张大图，而真正界面用到的图片只占了大图的很小一部分，这不仅浪费了贴图内存，而且降低了合批效率的问题，提升了合批效率并且降低了资源浪费；再一方面，通过根据压缩纹理数据的格式创建物理贴图；最后对物理贴图进行划分得到与页面贴图尺寸相同的多个贴图区域，并根据待处理贴图在所述虚拟贴图中的位置，将待处理贴图对应的页面贴图的压缩纹理数据上传至贴图区域，使得可以对相同渲染状态的待处理贴图对应的压缩纹理数据进行合批，减少了渲染批次，进而提高了渲染速度。

下面，将结合附图对本示例实施例贴图处理方法中涉及的步骤进行详细的解释以及说明。

本公开示例实施例的目的在于游戏运行时将不同的压缩贴图，动态合并到同一张物理压缩纹理中，提供一种既能降低贴图的内存使用量，又能保证所有贴图都在同一张物理压缩纹理中，增加合批的可能性。

并且，在游戏中，一般存在两种类型的贴图纹理：一种是游戏运行前就存在的贴图，一般会离线压成高质量的GPU压缩纹理；另一种是游戏运行时动态生成的纹理，如字体纹理。为了更好的合批和节约内存，可以将字体贴图实时压缩，并上传到同一张压缩纹理。为了实现上述目的，提出了一种基于压缩纹理动态合并、字体纹理实时压缩的贴图处理方法，可以包括以下几个方面：

一、将贴图切成固定大小的Page(页面)贴图，以Page为单位进行贴图的加载、卸载、动态合并。由于每张贴图的尺寸不一样，如果直接以贴图为单位进行动态合并，如何找到一个合理大小的空隙来摆放贴图是一件很困难的事，其最优解是较为困难的。本公开提出将贴图切成固定大小的Page贴图，由于每个Page的尺寸是固定的，因此很容易实现贴图的动态合并。

二、由于一张逻辑贴图可能会被切成多个Page贴图，而本来相邻的Page贴图没法保证在合并的物理贴图上也是同样的相邻关系。因此，Page贴图的四周需要留出一定间隙，间隙大小跟shader(着色器)中采样贴图的sampler采样方式有关，如果是线性采样，至少需要留出1个像素的间隙；如果是非线性采样，则需要留出对应的间隙。留出间隙的像素，使用Page在逻辑贴图上相邻的像素颜色值来替代，这样才能保证采样的正确性。

三、一张贴图会被切成多个固定大小的Page贴图，并且分散在物理贴图的各个位置，因此涉及到如何将分散的Page贴图完整的进行渲染。可以通过基于CPU的图元切分和UV转换以及基于GPU的UV转换。

四、对于字体贴图，考虑到TrueType(矢量字体)的字体在不同DPI(Dots PerInch，每英寸点数)设备上渲染得到的字体bitmap(位图)可能会不一样，一般都会在具体设备上实时生成字体贴图。这样的字体贴图和离线压缩的贴图格式不一样，没法合批。因此，可以通过一种基于ASTC(Adaptive Scalable Texture Compression，自适应可缩放纹理压缩)的字体贴图实时压缩算法，在保证压缩字体贴图信噪比的同时，大幅提升压缩效率。字体贴图按照Page(页面)为单位进行实时压缩，使得字体贴图和普通的压缩贴图动态合并到同一张物理贴图中，提供文字和普通贴图节点进行合批渲染的可能。

在步骤S110中，将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图。

在本示例实施例中，上述虚拟贴图的像素可以是64K*64K，也可以是其他像素，本示例对此不做特殊限制；所述虚拟贴图中的两个相邻的所述待处理贴图之间间隔有预设设像素，该预设像素可以是1个像素；两个相邻的所述页面贴图之间具有预设数量(例如可以是1个)的重叠像素，所述重叠像素的颜色值为所述页面贴图对应的待处理贴图的相邻颜色值。

详细来说，可以离线合并所有待处理贴图到一张64K*64K的超大虚拟贴图中。其中，虚拟贴图的边缘可以空出1个像素；然后，将超大虚拟贴图按照126像素的间距切成多个尺寸相同(譬如，当均可以是128*128像素大小，也可以是64*64或者256*256等很多类似的尺寸，本示例对此不做特殊限制)的正方形小图page；并且保证每张page贴图跟相邻的page贴图有1个像素的重叠，page贴图的逻辑大小只有126*126像素，边缘留出1个像素是为了保证sampler线性采样不受周围page像素的影响。

在步骤S120中，对各所述页面贴图进行压缩得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图。

在本示例实施例中，对所有的page贴图进行ASTC(或ETC，BC3等)压缩得到压缩纹理数据，其中，压缩block(块)为4*4，再将Page图片的压缩纹理数据保存成自定义的虚拟贴图文件。然后，再根据压缩纹理数据的格式，创建一张的物理贴图，其中，该物体贴图的像素例如可以是4096*4096，也可以是其他像素，本示例对此不做特殊限制。

在步骤S130中，将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域。

在步骤S140中，根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。

在本示例实施例中，参考图2所示，根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域可以包括步骤S210以及步骤S220，以下进行详细说明。

在步骤S210中，根据所述待处理贴图在所述虚拟贴图中的位置以及大小，从所述虚拟贴图中加载出与所述待处理贴图对应的一个或者多个页面贴图。

在步骤S220中，将与所述一个或者多个页面贴图对应的所述压缩纹理数据上传至所述一个或者多个贴图区域。

以下，将对步骤S210以及步骤S220进行解释以及说明。首先，根据待处理贴图在虚拟贴图中的位置和大小，加载对应的一个或者多个页面贴图，然后再将该图片对应的一个或者多个128*128大小的Page压缩纹理数据上传到贴图区域。由于每个Page边缘有1个像素border，并且该像素的颜色值为原始贴图中Page贴图的相邻颜色值，因此，无论虚拟贴图中相邻的Page在实际的物理贴图中UV是否相邻，都能采样到正确的像素颜色值。此处需要补充说明的是，由于一张UI图片可能包括多个页面贴图的，比如有一张200*100的贴图，则需要占用2个或者4个页面贴图，因此需需要根据待处理贴图在虚拟贴图中的位置以及大小(判断有几个页面贴图需要加载)，加载对应的页面贴图。

进一步的，为了可以将上述页面贴图的压缩纹理数据上传至正确的贴图区域，不会对其他纹理数据进行覆盖，该贴图处理方法还可以包括：对各所述贴图区域的当前状态进行记录；其中，所述当前状态包括空闲状态或者占用状态；当得到各贴图区域的处于空闲状态或者占用状态以后，则可以将与所述一个或者多个页面贴图对应的所述压缩纹理数据上传至所述一个或者多个处于空闲状态的贴图区域。

进一步的，当将所述压缩纹理数据上传至处于空闲状态的贴图区域后，该贴图处理方法还可以包括：对所述贴图区域中具有相同渲染状态的各待处理贴图对应的压缩纹理数据进行合批，并对合批后的待处理贴图进行渲染。通过对具有相同渲染状态的压缩纹理数据进行合批，可以大大的减少渲染批次，进而减少系统负担，提高渲染速度。

进一步的，在对待处理贴图进行渲染之前，贴图处理方法还可以包括：对所述待处理贴图的顶点数据进行转换；和/或对所述待处理贴图的UV数据进行转换。

在本示例实施例中，对所述待处理贴图的顶点数据进行转换可以包括：根据所述待处理贴图对应的页面贴图的网格，利用矩形将所述待处理贴图渲染至二维平面，完成对所述待处理贴图的顶点数据的转换。详细而言：

首先，对于待处理贴图的UV信息，按照切割Page的网格，进行软件光栅化。由于软件光栅化的计算复杂度很高，但是考虑UI节点的特殊性，大部分UI节点都可以用矩形渲染到2维平面，如果只考虑这种形式，可以很快完成顶点数据的转换。譬如，参考图3所示，ABCD是原始渲染矩形的顶点在虚拟贴图中的位置，EFGH分别是该贴图与切割Page的交点。该图片所占的4个Page可能会被加载到物理贴图的不同位置，因此在虚拟贴图情况下要渲染的ABCD矩形，需要转换为物理贴图的4个不同的矩形，分别是AE₁P₁H₁、H₂P₂G₂D、E₂BF₂P₄、P₃F₁CG₁四个矩形。确定了UV的映射转换，就可以等比例去转换顶点坐标，顶点颜色等其他属性。这样的转换简单快速，由于UI的特殊性，大部分平面UI都可以用这种方式表达，但对于复杂的3D三角形图元转换，计算会过于复杂，而且增加的顶点加重了VBO和vertex shader的开销。

进一步的，在本示例实施例中，参考图4所示，对所述待处理贴图的UV数据进行转换可以包括步骤S410-步骤S430，以下进行详细说明。

在步骤S410中，配置标签贴图；其中，所述标签贴图的像素与所述页面贴图的像素一一对应。

在步骤S420中，将所述页面贴图在所述物理贴图中的页面偏移的UV信息保存至所述标签贴图中。

在步骤S430中，根据所述待处理贴图在所述页面贴图中的UV坐标以及所述UV信息，得到所述待处理贴图对应的页面贴图在所述物理贴图中的UV坐标。

以下，将对步骤S410-步骤S430进行解释以及说明。首先，可以配置一张PageTable的物理贴图(标签贴图)，其像素一一对应虚拟贴图的Page(页面贴图)；然后，将对应虚拟贴图Page在物理贴图中的Page偏移的UV信息保存在每个像素的RGBA信息中；进一步的，在pixel shader中，结合虚拟贴图的UV坐标，和Page Table贴图中保存的信息，就能计算出该虚拟贴图UV在物理贴图中的UV坐标，然后进行采样。

如图5所示，如果需要采样虚拟贴图中的PointA颜色值，直接将PointA在虚拟贴图中的UV坐标传入Pixel Shader。在Pixel Shader中，根据虚拟贴图的UV坐标直接最近点采样Page Table Texture，能得到Page[i]对应的Pixel[i]点的像素值，该像素存放了虚拟贴图的Page[i]贴图加载到Physical Texture中的Page贴图偏移坐标(2,1)，结合公式(1)，能算出Page[i]在Physical Texture中的偏移UV。根据PointA在虚拟贴图中的UV，结合公式(2)，计算出PointA在Page[i]内的偏移，最后根据公式(3)能得到虚拟贴图中的PointA在物理贴图中的UV坐标。

pageUV＝PageOffset*PT_PAGE_SIZE； (1)

inPageLocation＝VT_PAGE_SIZE*fract(virtualTextureUV*VT_PAGE_NUMS_PER_LINE)； (2)

其中，PT_PAGE_SIZE为Page贴图在物理贴图中所占的尺寸大小，包含边缘，根据2.2的Page切割方式，PT_PAGE_SIZE＝128；

VT_PAGE_SIZE为Page贴图在虚拟贴图中的尺寸大小，不包含边缘，根据2.2的Page切割方式，VT_PAGE_SIZE＝126；

VT_PAGE_NUMS_PER_LINE为虚拟贴图中一行数据所包含的Page数量，如果虚拟贴图的大小为64512像素，那么VT_PAGE_NUMS_PER_LINE＝64512/126＝512；

PAGE_BORDER为Page贴图的边缘大小，PAGE_BORDER＝1；

PT_TEXTURE_SIZE是物理贴图的尺寸大小。

进一步的，对于运行时生成的字体贴图，根据字体贴图的特点，进行快速实时压缩，将压缩好的字体贴图按照128*128像素的大小，上传到物理贴图的空闲Page中。虽然字体贴图只有alpha通道，但考虑文字需要和普通图片节点进行合批渲染，因此字体贴图压缩之后在shader中采样得到的RGBA数据需要为(1.0,1.0,1.0,alpha)。同时，将文字的颜色跟普通的UI图片节点一样，作为顶点颜色属性上传到GPU，这样在Pixel Shader中gl_FragColor＝diffuseColor*texture(tex,uv)，和普通的UI图片节点保持一致，因此文字和图片节点可以使用同样的简单shader进行合批渲染。

此处需要进一步补充说明的是，对于离线的贴图压缩工具，不管是ASTC还是ETC，BC，都存在压缩的性能开销过大的问题。因此我们针对字体贴图的特点，提出一种基于ASTC格式的高效，高质量的字体贴图实时压缩方法，其主要思路如下：

离线的ASTC压缩算法，需要遍历partition，plane，以及各种其他mode，从而选择一种较优的格式进行压缩，一般性的遍历和高信噪比的选择使得离线压缩算法性能很差，无法满足实时压缩贴图的要求。根据字体贴图只有alpha通道的特点，结合合批的要求，字体贴图需要采用RGBA(1.0,1.0,1.0,alpha)的格式，因此采用Luminance+Alpha的模式，其中Luminance固定为0xFF。所以我们选择固定的一种模式：单一平面，单一partition，CEM为LDR Luminance+Alpha Direct的2D贴图，其中Luminance的值固定为1.0，即ASTC格式中的0xFF。对于color endpoint，由于只有alpha通道是有效值，所以直接在一维的alpha上选择最小最大值作为两个color endpoint。对于weight选择每个texel一个独立weight的方式，即对于4*4的block，需要16个weight。利用ASTC的weight和color endpoint可变长的特点，结合Integer Sequence Encoding(ISE)压缩编码，weight和color endpoint可以采用两种编码方式：

编码方式一：每个weight占5bit，范围[0,31]；每个color endpoint value采用6bit+1Trits的ISE压缩编码方式，即平均每个color endpoint value占7.6bit，范围[0,191]。这样16个weight需要80bit的空间，4个color endpoint value占用31bit，结合该模式下需要的17bit配置信息，刚好为128bit的空间大小。

编码方式二、每个weight采用3bit+1Trits，即平均每个weight占4.6bit，范围[0,23]；color endpoint value可以使用8bit的编码方式，范围[0,255]。这样16个weight采用ISE压缩编码，需要占用74bit，4个color endpoint value占用32bit，结合该模式需要的17bit配置信息，总共是123bit的空间，weight和color endpoint value之间空余5bit。

两种编码方式的优劣势对比如下表1所示：

表1

	weight精度	endpoint精度
			编码方式一	高	低
编码方式二	低	高

因此以上两种编码方式各有特点，可以根据block的实际情况进行选择，但是总的来说，对于大部分情况，编码方式1比编码方式2的信噪比更好。

对于压缩过程中需要进行的数据转换，都采用离线预计算对应的数据转换映射Table，在运行时直接查表获取转换结果。

如color endpoint value的6bit+1Trits的ISE压缩编码，根据ASTC的手册，离线计算[0,191]范围的每个整数值(encode value)对应的endpoint unquantization数值(decode value)；对于[0,255]的每个整数i，选择一个最佳的encode value，使得该encodevalue对应的decode value和整数i的误差最小。将该最佳encode value的值存到一维数组的table[i]位置。从而对于每个color endpoint value，直接查表就能获取[0,191]范围内的最佳encode value。

对于1Trits的ISE数据压缩方式，同样根据ASTC的手册，离线计算出5个Trits对应的T0～T7的8bit ISE压缩数据，然后保存成table，在运行时直接查询得到ISE压缩数据，再按照trit-based packing的约定编码到对应的数据位。

对于weight的选择，我们也通过离线计算查询表格的方式。对于每一个在0～255范围内的MaxDiff，根据weight的编码方式和所占的字节数，计算在0～MaxDiff范围内的每个Diff对应的最佳weight，并将weight按照bit反转，将结果保存在[MaxDiff][Diff]的二维数组中，这样可以直接在运行时查表获取weight的编码值。

以下，以ASTC，block大小4x4为例，weight和color endpoint value采用方式一进行压缩，来说明字体贴图的实时压缩方法。参考图6所示，其压缩流程图如下：

步骤S601，计算4*4block的alpha最大值maxAlpha以及最小值minAlpha；

步骤S602，判断最大值maxAlpha与最小值minAlpha是否相同；若相同，跳转至步骤S608；若不同，则跳转至步骤S603；

步骤S603，直接写入字体贴图对应模式的Block Mode和CEM；

步骤S604，查表获取maxAlpha以及minAlpha对应的encode value，和两个Luminance＝0xFF对应的encode value一起为4个endpoint值；

步骤S605，查表获取4个endpoint值的高位Trit ISE编码，和低位组成31bit的color endpoint encode value；

步骤S606，根据maxAlpha以及minAlpha的encode value值，再次查表获取decode的minDecAlpha，maxDecAlpha；其中，maxDiff＝maxDecAlpha–minDecAlpha；

步骤S607，对16个texel的alpha，diff＝alpha–minDecAlpha；根据maxDiff和diff，直接查二维Table得到对应weight的bit反转结果，并将结果写入压缩数据中；

步骤S608，单颜色模式，直接写入block。

在Intel Core i7-8700 3.2GHz CPU上的测试结果，对于常用的1300个汉字生成1024*1024的字体贴图，使用离线的astcenc(一个ARM公式开发的ASTC标准压缩库)和本文的实时贴图压缩算法进行block 4x4的压缩，其对比结果如下表2所示：

表2

压缩方法	单核运行时间(ms)	压缩信噪比(dB)
			astcenc(very fast)	966.4	47.1
astcenc(exhaustive)	127015.3	55.4
			本文实时压缩算法	3.9	51.3

本公开示例实施例提出的针对字体贴图的ASTC实时压缩算法，不仅性能是astcenc(very fast)算法的250倍，而且压缩贴图的信噪比也要高4.2dB。

进一步的，基于Page大小的纹理动态合并，保证了游戏只需要加载实际用到的贴图数据，节约内存的同时，又能使所有贴图数据都合并在同一张物理贴图中，增加了合批的可能性。对于字体贴图，在保证字体贴图信噪比的同时，又能高效的进行实时压缩，并按照Page为单位动态合并到同一张物理纹理中。经过压缩之后的字体贴图在pixel shader中读取的RGBA像素值为(1.0,1.0,1.0,alpha),直接乘以字体颜色就能得到文字pixel shader的输出结果，和普通UI节点的shader保持一致，因此可以将文字和普通UI节点进行合批渲染。基于压缩纹理动态合并、字体纹理实时压缩的贴图管理不仅降低了UI的贴图内存使用量，也大幅提升了渲染合批效率，提升了渲染UI的性能。

本公开还提供了一种贴图处理装置。参考图7所示，该贴图处理装置可以包括虚拟贴图切分模块710、物理贴图创建模块720、物理贴图划分模块730以及数据上传模块740。其中：

第一切分模块710可以用于将待处理贴图离线合并至具有第一预设像素的虚拟贴图中，并按照第二预设像素对所述虚拟贴图进行切分得到多个页面贴图。

拟贴图切分模块710可以用于将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图。

物理贴图创建模块720可以用于对各所述页面贴图进行压缩，得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图。

物理贴图划分模块730可以用于将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域。

数据上传模块740可以用于根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。

在本公开的一种示例性实施例中，所述贴图处理装置还包括：

合批模块，可以用于对所述贴图区域中具有相同渲染状态的各待处理贴图对应的压缩纹理数据进行合批，并对合批后的待处理贴图进行渲染。

状态记录模块，用于对各所述贴图区域的当前状态进行记录；其中，所述当前状态包括空闲状态或者占用状态；

第一转换模块，可以用于对所述待处理贴图的顶点数据进行转换；和/或

第二转换模块，可以用于对所述待处理贴图的UV数据进行转换。

所述物理贴图的像素为4096*4096；

所述页面贴图的像素为128*128。

上述贴图处理装置中各模块的具体细节已经在对应的贴图处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

在本发明的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图8来描述根据本发明的这种实施方式的电子设备800。图8显示的电子设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图1中所示的步骤S110：将待处理贴图离线合并至虚拟贴图中，并对所述虚拟贴图进行切分得到多个尺寸相同的页面贴图；步骤S120：对各所述页面贴图进行压缩得到与各所述页面贴图对应的压缩纹理数据，并根据所述压缩纹理数据的格式创建物理贴图；步骤S130：将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域；步骤S140：根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备800也可以与一个或多个外部设备870(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备800交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本发明实施方式的方法。

在本发明的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

根据本发明的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

此外，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

本领域技术人员在考虑说明书及实践这里发明的发明后，将容易想到本发明的其他实施例。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未发明的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由权利要求指出。

Claims

1.一种贴图处理方法，其特征在于，包括：

2.根据权利要求1所述的贴图处理方法，其特征在于，在将所述待处理贴图对应的压缩纹理数据上传至相应的所述贴图区域之后，所述贴图处理方法还包括：

3.根据权利要求1所述的贴图处理方法，其特征在于，根据所述待处理贴图在所述虚拟贴图中的位置，将所述待处理贴图对应的所述页面贴图的压缩纹理数据上传至所述贴图区域包括：

4.根据权利要求3所述的贴图处理方法，其特征在于，在将所述物理贴图划分为多个与所述页面贴图尺寸相同的贴图区域之后，所述贴图处理方法还包括：

5.根据权利要求1所述的贴图处理方法，其特征在于，所述虚拟贴图中的两个相邻的所述待处理贴图之间间隔有预设像素；

6.根据权利要求2所述的贴图处理方法，其特征在于，在对合批后的待处理贴图进行渲染之前，所述贴图处理方法还包括：

对所述待处理贴图的顶点数据进行转换；和/或

对所述待处理贴图的UV数据进行转换。

7.根据权利要求6所述的贴图处理方法，其特征在于，对所述待处理贴图的顶点数据进行转换包括：

8.根据权利要求6所述的贴图处理方法，其特征在于，对所述待处理贴图的UV数据进行转换包括：

9.根据权利要求1-8任一项所述的贴图处理方法，其特征在于，所述虚拟贴图的像素为64K*64K；

所述物理贴图的像素为4096*4096；

所述页面贴图的像素为128*128。

10.一种贴图处理装置，其特征在于，包括：

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-9任一项所述的贴图处理方法。

12.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-9任一项所述的贴图处理方法。