版本: 3.5.0 (我从 3.4.1 开始使用, 发现一直如此)
我写了个组件用来查看动态图集内容, demo: dynamicAtlas.zip (140.9 KB)
发现动态图集算法可能有问题,
一旦加入略大碎图 (大蓝框), 就容易产生巨大浪费空间. 小图片(小蓝框)不再被填入空白区域. 如果没记错, Laya 不会出现这种问题.
请不要建议我不放入大图片…我的实际项目中, fnt 资源 512 左右并不算大, 浪费的空间却很可观.
希望官方可以先给个临时解决方法，然后再在后面的版本里面优化，优化完后在发布的版本更新日志中突出显示
现在感觉 cocos 每发布一个版本, fix 赶不上 bug 产生的速度…更别提优化了
看了下源码。现在的实现比较粗暴，放不下就直接跳过了这块空白区域。等不及更新自己改吧。 
改一下引擎吧，我写过一个合图算法，在这里
对我来说这暂时不是必须解决的问题.
改引擎难免给自己增加维护成本, 我通过 prototype 替换了一些内部逻辑, 如果将来引擎更新了直接去掉就好了.
然而始终, 许多明明官方很容易解决的小问题, 就是不更新…就很怪
官方人力不足，也在一直招人
团队目标不是解决这些小问题，所以就会这样，我以前不理解，现在懂了。
其实改动很小的，效果还是比较明显的，我认为引擎自带的合图几乎不能用，那个效果无法接受。
怎么用prototype 改的，能细说下吗
官方所有优化问题都是客户端程序的问题 只要功能能跑就不是我的问题
说句实话 现在引擎组功能都做不完 哪里有时间做优化 就像产品给你提需求一样 你需求都没有做完 哪里来的时间考虑做优化 肯定是优先考虑完成功能
我感觉他们挺闲的 
.
比如 3.5 编辑器增加了 “2D 项目不让修改 z 坐标 / 不让 x/y轴旋转” 之类… 没看出有啥实际意义 ( 用 3D 方式 呈现 2D 元素不是很常见的需求么, 好嘛直接不让你用) (看引擎源码, 推测可能因为 2D assembler 大部分没考虑 3D 变换的情况, 导致 3D 变换后点击测试失效之类, 干脆偷个懒, 屏蔽之…)
哈哈 你终于意识到真相了，，遇到问题他们选择的方式就是屏蔽掉
@jare 这两天网上找了一下资料 发现有开源库，官方可以参考一下
https://github.com/villekoskelaorg/RectanglePacking
https://github.com/DaVikingCode/UnityRuntimeSpriteSheetsGenerator
（这个是Unity的，也是参考了上面第一个的算法）
1赞
动态图集和自动图集不一样，老用户可能会关注到自动图集的算法我们经过了多轮优化，已经十分接近理想情况。
动态图集我们追求的是动态性能，而不是空间。用户可以自己预估哪类尺寸的图允许动态合图，哪些图不适合进入合图，并且如果对空间有那么高要求自己合图比较好。
团队目标就是解决这些小问题，产品就是由无数魔鬼般的细节组成的，这也是商用引擎和私有引擎最大的区别。
我十分理解大家的心情，每个需求、每个 bug 在用户眼里都是最优先的，但是在项管看来，首先要对问题进行分类，不同问题分派的岗位不同。再来看这个岗位的同学手头是否有其它更重要的事情。
Unity 和 Rect / Max Rect 算法的版本，不适用于实时渐进式生成，性能达不到要求。
这里面一个本质区别是，动态合图是渐进式的，普通的合图算法是一次性的并且有很多次的重试寻求最优解。
前者是未知后续会有什么新的图片加入的情况下持续不断的添加到合图中，算法无法预估后续会有什么尺寸的图进来。这是一个空间浪费比较大的原因。
我们之后会排期再调研一下算法，优化一下合图方案，我个人觉得可以考虑采用分帧合图，逐步降低 drawcall。不论如何都感谢楼上提供方案的同学们！
后续我们会在 https://github.com/cocos/cocos-engine/issues/11196 继续跟进这个问题
3D 游戏里面就没有 2D assembler 了吗？
大家都是研发，起嘛的职业操守、技术追求都是有的吧？
我们这里的人，如果没有追求，去做游戏不香吗？去大厂不香吗？为啥要在一个小公司坚持被大家骂呢？
正常产品都不可能做出这种屏蔽掉的蠢事，如果我们这么做了，研发同学们也会造反的。
更何况 Creator 是一个已经立项了 8 年的产品，Cocos 3D 也立项 5 年了，如果没有坚持长期主义的决心，早就崩塌了。
大家既然使用了 Creator，这点起嘛的信任是要有的吧？
如果我们的某些行为，让你们真的觉得我们喜欢“屏蔽 bug”，那么欢迎私信我投诉，我一定严肃处理。
1赞
自动图集构建速度非常慢（Creator 2.4.9），而且好像没有用上缓存（新克隆的项目第一次构建和第二次构建用时基本一样）。项目中加上很多自动图集之后（几百个），打包时间从20多分钟暴增到快2个小时，而且过程中CPU占用、内存占用、磁盘占用都很少，机器闲得很。可以麻烦看一下是否是自动图集的并发数量被限制了吗？看一下是否可以简单地增加一些并发量比如设置成CPU核心数量或者2倍，麻烦的话就算了。
是不是用了压缩纹理？我记得是支持缓存的，不行的话排查一下是不是安装了什么插件导致的。如果还是没有缓存麻烦发个 demo 我们试试。
我的意思就是这样，问题是需要排队的，但是有点离谱了：
动画编辑器快捷键，从1.X就有提了，整个2.X都没有，到3.X 才加入。2.X直接享受不了。
来，这个问题，2年了吧。