Creator编辑器槽点和改进建议(追加纹理压缩缓存)

什么版本会有,加上纹理压缩之后,构建时间一个多小时,急需这个功能

我最近也在研究这个问题,目前的方案是构建的时候把pac都删掉,正式出包的时候才真正合并图集

我这里有个改进思路,要引擎组实现:
1 第一次纹理压缩时,记录每个图片的md5,缓存在一个文件里面
2 后面每次压缩,对比md5是否发生变化,如果新增或者是改变之后才重新压缩

之前creator不带纹理压缩功能时,我们自己实现时,也是这么做的,希望引擎大佬改进下

@jare

1赞

更新:
追加:纹理压缩缓存

就像unity的这个复制组件功能,怎么实现

我们也有这个需求, 同求

已实现,将在 2.2.2 落地

1赞

求跳过 2.2.1 直接发 2.2.2

这个在打包时候尤其明显,那时间直接延长了两倍啊。无法忍受呀,尤其是在调试 jscallJava / javacallJs,
头都能大一圈。不得不删掉之前压缩文理的部分。

自从发现每次构建都是重新计算一遍图集我就放弃用自动图集了,改为TP打好再压缩下丢工程里用了,这样反而包体还小了。
事实上它构建时打出的图集和预览时产生的图集是一样的。
毕竟图集产生时用的算法及设置参数相同的情况下是不会变的,对比下预览缓存目录的图集算法及参数,构建时参数相同则直接复制过来就可以了啊。没有的情况下才再去生成一个多好。。。。

@EndEvil

2.1.2 就没有重新构建图集了

纹理压缩缓存挺重要的,每次构建都要重新压缩耗时太长。
本来想用gulp转etc1,用上gulp-cache,结果转完了读的还是png原图,没搞清楚引擎是怎么确定应该读pkm还是png

2.2.1没跳过,2.2.2倒是跳过了,直接2.3了:smiley:

泪崩:joy:

迫切需要:
纹理压缩缓存
资源和脚本分开导出


项目大了,到后期接sdk,改动一点点脚本,全部资源+脚本都要重新导出纹理压缩,没几个小时下不来

这个确实,一眼觉得这个不优化也没啥,但是一碰到父节点适配选四个位置就会在内心吐槽一遍

toggle组件 加个隐藏背景的选项, 不是每个开关都只需要把checkmark叠加显示在上面:weary:
很简单的功能 但是每次自己写很烦

问题:构建时,纹理压缩过程是单任务,即每次只会压缩一个图片,不能发挥CPU的多核性能,图片较多时,压缩过程极为漫长。
建议:增加根据CPU规格情况开启多任务分批处理资源的功能,尽可能发挥CPU的多核性能,节省构建时间

可能是因为这个原因,改成了单任务