应该只有2.x有问题。
3.X 用的少 ，也没有截图需求。所以不知道。
box2d 里本已经集成了liquidfun，但是没有暴露出来，这个看能不能补回来，很有用啊。
能帮忙介绍一下吗？在这里建个 issue， https://github.com/cocos/cocos-engine/issues/new?assignees=&labels=Needs+Triage%2CFeature+Request&template=feature_request.yml
看看编辑器需要提供什么组件，引擎需要有什么 API？
谢特，要写英文吗。
liquidfun 是物理粒子，通过改变粒子属性来模拟软体/流体/粉尘 等等效果。
对应cc.RigidBody，可以做一个 cc.ParticleBody。
用来创建和控制 软体 / 物理粒子，可以具体到一个粒子。
提供4种回调， begin, end, preSolve postSolve
好，你用我帮你搬运一下
我提issue了，这比写代码还难。
Liquidfun is built-in engine, but no public API found. · Issue #11220 · cocos/cocos-engine (github.com)
1赞
纯 2D 项目不存在透视相机，你们需要以 3D 方式呈现的话，那就属于 3D 项目了，需要勾选 3D 模块，所以不应该遇到这个问题才对。当然，3D UI 的官方版本我们也在规划中了，到时候同样会做为 3D 模块上的能力提供出来。
就是因为我们想要稳一点，所以目前精力大部分是放在非功能性上，例如性能、渲染管线、材质系统、稳定性修复上。这些底层工作在开发者看来感知是很不明显的，但确实一个现代引擎必不可少的部分。
但是引擎也不能没有 UI 呀？不能没有音频啊？物理、粒子、Prefab、Spine、资源管线…… 这些也是要做到完美的话，那给我们 5 倍的人才够。（大户人家也养不起这么多家丁的）
到了性能层面，自动图集、构建压缩、动态图集又是不是地基呢？把动态图集砍掉，就不会有这个帖子了，这样皆大欢喜了就？
所以到了地基这个层面，一样是需要排序的。只有引擎能解决的地基我们会优先解决，开发者能自行优化的地基我们就会先适当延后。
动态图集，本来就可以关闭的，我们也不是默认所有平台都开启。照你这么说，大家把这个功能关掉就好了。
所以在我看来，所谓半成品的定义就可能是缺乏良好界定的。
因此我们今天能采取的策略，只能是尽可能划分清楚边界，给予开发者合理预期。对新功能尽可能标记为实验室，鼓励开发者充分进行评估再使用新版本和新特性。
从 1 - 10 的难度远远大于从 0 - 1，以 DrawCall 优化为例，社区确实有“完美”方案，【YH Multi UI】- 最简单粗暴的《DrawCall优化方案》 但是一旦推广开来，各种姿势去实际使用，最终暴露的问题也是很多的，平台兼容性上也没办法做到完全兼容。更何况这个方案真的完美吗？今天的 GPU 硬件真的需要所谓的 One Drawcall 吗？一个通用引擎，一旦考虑到产品化、通用化，稍微增加一点东西，面临的工程量、维护成本都大到你无法想象。
因此今天所有 B 端产品，都是不断迭代而来的。你会觉得一个东西成熟稳定，那是因为它已经经过了很长时间的发展，踩了很多坑，有了大面积的实战反馈。
Creator 从立项之处，只是想做一个小而美好玩的东西，当时连渲染引擎都没有（Fireball 0.4）。后来转型 H5、小游戏（1.8），到原生（2.2），再到 3D（3.0），每一步都在扩大用户面，用户需求、项目类型、项目规模、团队规模的变化是不断在发生的。
每个功能在实现之初，边界是清晰的，随着用户需求的变化，边界会不断扩大。
我们唯有不断适应产品发展的需要，让各个模块能够支撑越来越大的项目，越来越复杂的使用场景。
这不是摆烂，这就是今天引擎不断发展的事实。各个模块的发展有先有后，人力有限没办法一次性全部做好，更没办法一次性满足所有类型的游戏品类。短板我们尽量补，大家的意见，只要言之有物，我们都会虚心接受。
这不是摆烂，该改的我们会不断改进。API 的预见性、架构的伸缩性、功能的稳定性。
但是我发现即便我们用尽全力，也没有生态快，也没有生态客制化能力强。感谢生态的力量，良好的生态是我们发展最大的动力。
1赞
我只负责推动问题的解决，吹牛逼画大饼不是我的本职工作。
所以关于你说的人的问题，我没有必要去跟你杠，杠就是你对。
针对你个人的言论，如果你觉得经常在技术板块说一些于事无补的、主观的、情绪的、关于人的、对发展和进步没有帮助的种种言论，是可以被我个人容忍的行为，那就错了。
针对其它个别同学，想要唠嗑，去非技术板块，别在这里影响大家进步。
DC党头号杀手是我，见一个杀一个
害多大点事情 无所谓
呃, 编辑器的问题并不重要. “问题” 主要是指, 透视模式下, 游戏运行的时候:
- Sprite 渲染不对 (Simple 类型)
- UITransform / Mask 击中测试不对
- WebView / VideoPlayer 的 impl 位置不对
- 相机被锁定的位置不对导致 Canvas 不能正确适配屏幕
这些问题我们都通过 prototype 替换解决了.
与勾选 “基础 3D 功能” 无关 (反倒使构建后增加了 20KB+ 传输尺寸).
如果官方将来要支持 3D UI, 但愿不是从头搞一套. 因为显然大部分 “纯 2D” 功能稍作修改就能完全兼容 3D 模式.
谢谢反馈，我们会评估一下，3.6 可能就会加上这块的支持
你们是不是要求有点高啊？经过这么久的折腾，我已经不希望ccc能出什么牛逼的贼棒的功能了，我只要求尽量少搞出bug来就谢天谢地了，能先降低已有功能的bug率么？
1赞
你们是不是要求有点高啊？
没关系，大家的需要就是我们进步的动力
是否可以考虑把2.X作为LTS长期支持，好像今年维护完就没了. 3.X又还没完善
已经 LTS 一年半了呀
3.5.1的版本 快一个月了 还没有发布吗 现在3.5的版本都不能用于生产
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。