摄像机在不勾选AlignWithScreen时黑屏 - Creator 2.x - Cocos中文社区
这个问题也是老久了
虽然帖子里有解决方式，但是这样会导致 在编辑器中生效，3D镜头不能调整Z轴的问题。
可能你误解了我的意思.
我们的 2D 项目就是需要将 UI 以 3D 方式呈现(透视效果). 在 Canvas 相机启用透视模式后, Sprite 等渲染不正确, UITransform 击中测试有偏差…
不过我通过 patch 一些方法 (比如 UITransform.prototype.isHit ) 解决了这些问题.
本来期望新版应该会完善这些方面, 因为我觉得这是一个通用游戏引擎应该具备的能力. 结果却背道而驰, 甚至默认不能通过编辑器调整 z 轴了 (不得不勾选 “基础 3D 功能”).
这种情况就难免让部分用户觉得,这是在 “屏蔽 BUG”
cocos一直有一个让人很头疼的事情是，提供了一个解决方案，但是这个方案在开发者看来不好用，只能解决基本需求，如果要达到满意的效果，还需要自己努力，然后开发者不停吐槽，官方再跟进解决，其实这个问题我觉得主要在于，如果一开始官方就给了一个比较满意的效果需要花2-3倍的时间才能有这个功能，对于开发者来说，一个半成品还不如不要，但是cocos觉得至少我有了这个功能，只需要后续改进就可以，然后2边同时改进，引擎分叉再也不能升级，或者升级难度越来越大，最终停留在某个版本升不动了，cocos里面有很多功能都是这种状态，然后api就频繁变动，稳定性也不能保证，然后对于产品来说，我觉得需要去评估到底是时间优先还是功能完成度优先，我们为什么不换一种思路呢，宁愿提供少一点功能，但是每个功能至少不用开发者费心去优化不是更好吗，大楼要一层层盖，盖好一次稳一层，现在一下子起高楼，但是地基不稳，大家就很难受了
你们给我的感觉就是开始摆烂了
隔壁引擎没加盖 走呗
我比你还急，恨不得自己修！物理我们周四会有人入职，到时候可以把缺失的东西补一补
可以弄个优化引擎贴对有贡献的网友 给一定的奖励 应该有很多人愿意提交自己的代码或者方案
已经紧张到这样了么，哈哈哈哈哈，可不敢给那个新员工看到，会吓跑
3.x 还会这样吗？
应该只有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党头号杀手是我，见一个杀一个
害多大点事情 无所谓