几行脚本搞定压缩纹理缓存,打包速度快到起飞,Mac OS 10.15 & Windows10 均测试成功

http://docs.cocos.com/creator/manual/zh/publish/custom-project-build-template.html


也可以这样,自己弄个插件, 定制构建流程, 在引擎构建开始时使用多线程去做压缩纹理,等引擎到这步的时候,已经有缓存了就快了

1赞

好的 老哥,我这边将尝试使用该方法进行处理,有效果的话 ,我跟你讲,并分享给你

1赞

老哥,我在使用缓存脚本过程中,发现有的图片压缩失败 返回command failed wiwth return code 1,这是什么原因导致的呢,大部分图片都可以压缩成功,只有极个别会发生这种情况,导致最后打包失败

1赞

而且 res = subprocess.call(["./etcpacktool", fromPath, cacheDir] + sys.argv[3:])
返回 res为 -6

这最好能把失败的图片打包发上来, 才好分析,应该是压缩工具返回的错误码,脚本的确也有点问题, 应该把错误抛出去, 让引擎知道发生了错误

我尝试了 用原本的工具进行压缩这张图片,发现是可以的,但是用python脚本的话,这几张图片就会失败,但是其他图片都可以正常 ,我现在将尝试 使用shell脚本 编写中间层,然后尝试,是否跟python一样 拿几张图片是否失败 老哥等我消息 :wink:

更新 引擎从3.3开始又不支持压缩纹理缓存了

那可能是 bug 吧?

感谢提供的思路,我引擎是3.3.1,第一次打包的确很慢,但是后来根据你提供的思路发现了引擎的缓存路径,3.x是支持的,那我就不重复造轮子了

嗯, 2.4 以后都支持了

2.4.6版本,缓存有时有效,有时没用。求问,现在缓存命中的条件是啥?感觉git checkout,debug切换release,打包报错等,相关操作都有可能导致缓存失效,理论上图片一样不就应该用得上。

能不能帮解释一下打包纹理压缩缓存怎么命中,感觉打包就像是拼阳寿。突然行突然不行,命令行打包啥配置都没改。

同问 同问 同问

缓存机制肯定是个天坑!!只能用中间件,替换的

老哥,你知道哪里还能下载mali texture compression tool么?

如果你需要 MacOS 版我可以发给你