【建议】希望优化下纹理压缩

非常感谢 Creator 团队加入了纹理压缩,目前纹理压缩还有两个点希望大佬们优化:

  • 1 纹理压缩缓存
  • 2 ETC2 Android 原生支持

一 纹理压缩缓存

目前可以再 creator 中设置,针对不同平台的纹理压缩格式,非常方便;但是,每次构建,所有的纹理格式都需要 全部 重新生成,如果游戏重度,构建一次需要非常长时间。以下这个资源量:

i7配置,每次构建需要一个小时左右的时间,打包一次接近2个小时,耗费时间实在太长了。
什么概念?就是早上到公司,开始打包,打完包就可以去吃午饭了…:3:
如果发现打出的包有一点不对,改了一下UI,对不起再来一次…:8:

希望引擎大佬优化以下,以下提供一个 优化思路

  1. 第一次构建生成压缩纹理时,先保存纹理原始文件的md5值,然后备份压缩纹理;
  2. 后续构建查看原始文件的md5是否变化,如果变化了重新压缩并备份,否则直接拷贝备份

压缩一张大图的时间要好几秒,对比生成对比md5+拷贝要快很多,希望引擎团队优化

二 ETC2 Android 引擎支持

iOS引擎已经做了支持,但是 Android 还是需要开发者去修改一部分代码;2013年7月发布的Android 4.3 就开始支持ETC2了,ETC2 已经也已经非常成熟,希望引擎组支持一下。

关于这两点论坛里面很久已经有呼吁了:

1赞

ETC2 还是很有价值

之前 Android 不支持的 etc2 的主要原因还是为了兼容模拟器。

  • 之前我们测试发现,有模拟器不支持 GLES 3 (如当时发现的海马玩模拟器)。
  • 还有些设备用 API 查询是否支持 ES 3 时,返回的是 true,但实际上不支持,比如 TF 101。

我们会重新评估一下是否要开启支持。

很多模拟器的版本确实很低,不过份额相对少很多,加上因为 x86_64 的问题,也需要单独打包,建议先不考虑模拟器;
压缩纹理缓存的问题,麻烦优化下,感激不尽~~

@jare 纹理压缩缓存,加一下

或者把压缩纹理的流程开放出来

支持。
最近打多个平台多个渠道的包,
真心打到吐血

谢谢反馈,我们之后加一下

引擎的纹理压缩炒鸡不好用,根本不是站在开发者角度上考虑的需求~
我们把压缩纹理这一步改成自己的压缩脚本了~

请问哪一步不好用?

每个纹理(图集)配置确实是挺麻烦的,
如果能指定一个全局的配置
再支持对特殊的少部分纹理的单独设置基本觉得就完善了(在有全局配置的情况下,单独纹理多一个checkbox指定是否压缩来决定该纹理不压缩的特殊情况)

优先级:单独纹理配置 > 全局默认配置

我们项目目前的做法是直接查找metas替换大法来快速修改压缩配置

每张纹理单独设置,确实太麻烦了,我在这个帖子也提到了,希望加一个全局默认的纹理格式。
目前我的做法也是用脚本去修改meta文件。

希望尽快加一下吧,每次打包要等2个小时左右,痛苦

好像使用压缩纹理,会大大增大包体。我做了个测试:

因为背景图用的还是ETC1 RGB,如果用透明通道就是597*2了。

pvr / pkm是可以很高压缩率的。
cdn启用gzip压缩。
原生打出的包体本身就压缩了吧。

个别压缩过的图片,纹理压缩可能是会变大;

可以尝试下,把所有图片都压缩,看看打出来的包体是什么情况

另外就像楼上说的,压缩过的纹理文件,还可以用 gzip 在压缩一次


给个参考:纹理压缩之前,包体 2G 左右,压缩之后 750M左右

社区分享的缓存实现方法 几行脚本搞定压缩纹理缓存,打包速度快到起飞,Mac OS 10.15 & Windows10 均测试成功

1赞

我用的是cocoscreator里面的压缩纹理,你们都是自己用工具打的吗

可以分享一下你们项目中具体是怎样使用压缩纹理的吗,比如用编辑器处理的还是用工具自己打,各有什么好处,一整套流程之类的,让新人学习学习姿势

整个过程都用python实现,命令行一键打包,大致流程如下:
1 构建+纹理压缩,
2 加密+gzip压缩
3 生成 obb 包
4 生成 apk

纹理格式,也是使用python,一件修改纹理格式;这个最好是编辑器提供 各平台 默认纹理格式。

2赞