什么版本会有,加上纹理压缩之后,构建时间一个多小时,急需这个功能
我最近也在研究这个问题,目前的方案是构建的时候把pac都删掉,正式出包的时候才真正合并图集
我这里有个改进思路,要引擎组实现:
1 第一次纹理压缩时,记录每个图片的md5,缓存在一个文件里面
2 后面每次压缩,对比md5是否发生变化,如果新增或者是改变之后才重新压缩
之前creator不带纹理压缩功能时,我们自己实现时,也是这么做的,希望引擎大佬改进下
更新:
追加:纹理压缩缓存
就像unity的这个复制组件功能,怎么实现
我们也有这个需求, 同求
已实现,将在 2.2.2 落地
求跳过 2.2.1 直接发 2.2.2
这个在打包时候尤其明显,那时间直接延长了两倍啊。无法忍受呀,尤其是在调试 jscallJava / javacallJs,
头都能大一圈。不得不删掉之前压缩文理的部分。
自从发现每次构建都是重新计算一遍图集我就放弃用自动图集了,改为TP打好再压缩下丢工程里用了,这样反而包体还小了。
事实上它构建时打出的图集和预览时产生的图集是一样的。
毕竟图集产生时用的算法及设置参数相同的情况下是不会变的,对比下预览缓存目录的图集算法及参数,构建时参数相同则直接复制过来就可以了啊。没有的情况下才再去生成一个多好。。。。
2.1.2 就没有重新构建图集了
纹理压缩缓存挺重要的,每次构建都要重新压缩耗时太长。
本来想用gulp转etc1,用上gulp-cache,结果转完了读的还是png原图,没搞清楚引擎是怎么确定应该读pkm还是png
2.2.1没跳过,2.2.2倒是跳过了,直接2.3了
泪崩
迫切需要:
纹理压缩缓存
资源和脚本分开导出
项目大了,到后期接sdk,改动一点点脚本,全部资源+脚本都要重新导出纹理压缩,没几个小时下不来
这个确实,一眼觉得这个不优化也没啥,但是一碰到父节点适配选四个位置就会在内心吐槽一遍
toggle组件 加个隐藏背景的选项, 不是每个开关都只需要把checkmark叠加显示在上面
很简单的功能 但是每次自己写很烦
问题:构建时,纹理压缩过程是单任务,即每次只会压缩一个图片,不能发挥CPU的多核性能,图片较多时,压缩过程极为漫长。
建议:增加根据CPU规格情况开启多任务分批处理资源的功能,尽可能发挥CPU的多核性能,节省构建时间
可能是因为这个原因,改成了单任务