godot在做2d还是有一定的优势，但是企业用得较少
不好意思，回复略晚。
1 所有的子弹都是在屏幕可见范围内，上左右都有墙体，子弹在屏幕内反弹。
2 GPU粒子只能使用特定的材质，而且有UImeshRender的情况下，开启GPU会报错
3 下图是一张截图，gameLogic和physics也有，但是现在感觉不是主要影响因素
感谢回复，节点数一共不是32，只是单纯的子弹32个，每个子弹有2-3个子节点。游戏截图在上个回复里有，就不一一粘贴了。
感谢回复，有我自己的原因，太菜了，第一次接触，逻辑方面可能有问题
兄弟，踩了3个雷点：
- 这么大量的物理碰撞可以不用内置的物理，参考源码自己实现一套简化版，四叉树优化。
- 不能大量使用拖尾
- 不能大量使用uimeshRender
这么大量的 2D 碰撞体，是必须使用四叉树方案来优化性能的。利用四叉树方案把碰撞空间划分出来，再利用引擎内置的碰撞检测方法，在四叉树空间下手动检测碰撞。能有效减少同时加载大量碰撞体的时间、提高大量碰撞的效率。
在 3.x 版本上四叉树方案可以参考这个仓库：CococsCreator-public-technology-solutions/demo/Creator3.4.1_2D_QuadtreeCollision at 3.4.0-release · cocos-creator/CococsCreator-public-technology-solutions · GitHub
碰撞检测方法可以使用 intersect api 手动检测。多边形的碰撞矩阵可以使用多边形碰撞体的。
另外不知道为什么你要用 3D 粒子？3D 粒子相比 2D 粒子复杂度更高，内存占用更多，并且在 canvas 下还需要用 UIMeshRenderer 去转换世界矩阵，明显开销更多。
拖尾组件组件我没怎么测试过，不了解它现在的性能。但是这东西现在应该没法合批吧。如果会打断合批的话，建议不要加哦。
2赞
碰撞反弹效果可以自己利用三角函数实现，如果还需要复杂的物理效果，那就还是用 box2d 吧。参考这个方案改造一下引擎，优化 box2d 性能。
多边形碰撞体的矩阵尽量简单一点，不要太复杂，否则性能也会有影响。
主观臆断卡在cpu算物理碰撞吧，你这还没上敌机。。。建议不要用自带的物理引擎，有几个方案参考：
1.确定瓶颈，比如去掉拖尾看看帧率是否大幅提升
2.使用kdtree管理子弹和目标
3.简化碰撞算法和反弹算法
感谢回复，拖尾和粒子必须要使用的，我在找找其他的方法。碰撞我立马优化下，感谢感谢！
感谢回复，我按照大佬的建议在优化下，非常感谢！
碰撞体大多都是圆，极少数多边形
感谢回复，综合各位大佬的建议，我尝试优化一下，感谢！
这个没问题，需要再次划分四叉树空间。你调试看看。
不过这一块为什么写了两次？有点意义不明，我有点忘了啥原因。这是抄的 git 上 https://github.com/xjz1994/Collision 实现
OK，感谢
我用微信小游戏测试四叉树demo发现帧率就几帧，不知道大佬有测试过吗
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。