至于物理分组是否用刚体这个问题，可能就是引擎开发者和游戏开发者思想上的冲突。
在你们眼里可能觉得这样设定没什么，就是多加个刚体而已。但是在开发者眼里自己明明不需要的东西为了实现一些功能，必须把刚体捆绑进来使用，心里就觉得压抑。
在游戏开发中，使用物理就避免不了使用刚体，碰撞器，和碰撞分组，物理射线。，要设用物理就会用到分组，不可能场景了几百个物体都是default碰撞层。但是要做分组就必须涉及刚体，这就导致了很多静态物体，如地面，建筑，石头这些都要加刚体，碰撞器无法做到独立使用，数量多的时候一个一个加刚体就很烦人。我现在用creator3d做项目，用到物理引擎基本能保证要给每个碰撞器强行加刚体，否则无法使用。还有和我相同的从unity转过来使用creator3d开发h5的朋友，看到你们的这种设定也是半天没缓过来，明明unity简单一个碰撞器就能做分组事，到了creator3d，全部要附加刚体。
你们引擎组不接触正式游戏开发的话，是体会不到开发者使用引擎时那种压抑心情
还有个问题，物理碰撞分组目前只能在编辑器设置。无法在代码里动态控制碰撞组间是否可以碰撞，或者两个碰撞器是否可以碰撞。在游戏开发中这些功能是非常常用的。
类似unity这种动态控制碰撞的函数
Physics.IgnoreCollision(collider1,collider2, 是否忽略)。//是否忽略两个碰撞体碰撞
Physics.IgnoreLayerCollision（layer1，layer2，是否忽略）//是否忽略两个图层的碰撞体之间的碰撞
目前c3d物理功能的灵活性比较低
像unity那种layer管理，开发了这么多游戏，大多项目都做得过来。像creator2d，一个group管理渲染和碰撞，对付目前各种游戏都游刃有余。你在creator3d搞这个复杂的layer和group分开管理方式，别人一定用得上很复杂的层管理项目吗，概率比较低吧，真有特别复杂的情况，多创建几个layer，再通过代码动态修改layer也能办得到。
主要是我有用一個3D平面，讓我在滑鼠點擊時，用射線檢測得到平面的x,y座標（如圖）
但移除RigidBody組件就又回到跟1.一樣的情形了。
所以才會有用不到剛體但需要分組的情況。
如果有更好的方式，或是滑鼠點擊取座標的方法，我可以學習一下。
分开layer 和 group是没问题的，但是layer只要通过节点设置就好了，而物理 group 得通过组件设置（每次设置还得展开组件去改属性，操作麻烦。
而且有的 静态物体/不需要物理模拟的物体 只需要BoxCollider 碰撞盒，但是碰撞盒却不能通过编辑器设置 group/mask，代码里都是可以设置的，这增加了编辑的成本。
BoxCollider 可以设置 Group 的，只是得通过脚本来设置 collider.setGroup(group),你可以自己写个脚本代替RigidBody 设置值。（还有，其实你这个方式把 IsTrigger 勾上也不会有碰撞啊
我也觉得layer和group分开没毛病，本来就是两个层面的东西。但分开之后也要考虑易用性的问题
其实你开发过程中会发现，很多时候layer和group里的值和名字会设置成一样。
例如：
玩家 layer：player， group：player
敌人 layer：enemy， group：enemy
子弹 layer：bullet ， group：bullet
从层的意义上讲，你找不到让layer和group命名不一样的理由。搞了半天，发现拆分和不拆分没什么不一样，还不如不拆分
也不会，如果不区分物理，玩家、敌人、子弹理论都可以是同一个 layer。（但是对于复杂游戏来说，可能需要特殊处理玩家/敌人/子弹的 显示，这个时候 分 layer 有用
这是我之前说的问题，c3d的layer只是渲染用的，你设置同一个layer还不是为了同一个摄像机渲染。但是不同层的情况，我同一个摄像机也可以渲染多个层。都是换汤不换药。
一个射击游戏里，玩家，敌人，子弹 这些互相交互的元素，你见过有谁会用3个摄像机分别渲染这3种物体，真要动态显示隐藏这些元素，直接在代码里修改节点的层就办得到了，为这次存在于理论上的做法去拆分层管理不值得吧。
吐槽一个点，layer在场景编辑器里为什么还是和射线检测耦合在一起的，改了layer之后就无法在场景编辑器里面选中了。
这种小问题，我觉得连讨论的必要都没有。
你没用过c3d的物理做游戏，当然体会不到那种难受的心情
场景编辑确实少很多重要的功能，就是开关光照、开关雾、显示框线、网格对齐等等，反正在C3D里搭建场景也是让人抓狂
感謝，真的是受教了XD
之前果然是多此一舉。
我也觉得分开挺好的，刚接触3D，用起来还可以。不好的是BoxCollider一定要在代码设置group，只能直接多写个脚本来控制。现在静态物体就是用BoxCollider+IsTrigger+自己脚本控制group和mask
分开来就是用起来复杂一点，但是带来的可能性就高，好过到时候大项目进来，无法拓展，束手束脚的。到时候引擎组再来修改考虑的东西就多得多，反而不如现在就培养起用户的使用习惯来得好。引擎不是向某个已有的好引擎看齐就好，还得有远虑，要不然人家一个新版本出来，新功能新特性，然后再去追？
不过确实对原unity的用户不友好，引擎组应该考虑怎么优化使用复杂度，或者两种模式给开发者选。
从设计角度来说，有两点我们坚持拆分的原因
渲染组 * 物理组 <= 20，也就是说如果有 5 个物理组，可能只有 4 个渲染组可以设置，而对于大项目来说，且不说单场景可能会超过，多场景的情况下，可能用户希望用不同的意义来区分渲染组，比如
除此之外就是建议参考 Unity 论坛中的吐槽，设计层面可能没有绝对的对错，更多是一种权衡和选择，对于这个问题我们仍然相信我们自己的设计是可以被开发者所接受的，我们也没必要硬靠友商的设计，更何况这是我们思考过利弊的选择。
目前我们建议是先设置好更完善的分组，在运行时随时切换 group 即可。当然你说的 API 也可以考虑
layer 是 Node 属性主要是因为渲染的级别确实比物理更高，所有游戏都需要渲染，渲染分组放在节点中是可以接受的（内部也在讨论是否要下放到 Renderable Component 内）。除非必要，我们一般是不会往 Node 上加属性，看上去方便，但是带来的长期技术枷锁是非常严重的，所以 group 就放到了物理组件中。至于 Collider 是否要允许在面板中直接设置 group 可以和 @JayceLai 讨论
感谢专业的回答，其实对于 group 的设置方式，我们做了很多方向的考虑
不使用的原因是我们不希望让节点增加过多的冗余数据，场景里面的物理节点毕竟还是少数
不使用的原因有两个：
在综合考虑了以上方案之后，较优的方案是在刚体组件上增加 group 属性，以上所有的问题都可以避免
总得来说，目前很多上层不友好的使用和设计，还是受限于底层的基础设施不稳，我们也在计划优化这些东西
未来我们会为 Bullet 后端增加逐 Shape Filter 的功能，在此基础上，还将重构为节点链组合刚体的架构，即时将带来以下功能：
除此之外，这个架构对编辑器内操作应该也是一个质的提升
其实市面上主流的物理引擎 PhysX / Bullet 的架构设计中，碰撞体都是必须附加到刚体中，刚体其实是必须的。
我们支持可以不加刚体组件，这并不是意味着没有刚体（内部其实会有个静态刚体）
我看材质的设置 是引用了材质，编辑器最底下就能直接编辑器材质。那么 只在属性检查器上增加一个group 属性设置 也是可以的吧，不一定数据上要放到 节点上，只要能方便编辑就行了。
现在编辑器内要搭建场景太难了。比如我拖一个模型到场景里，我就得手动加个 ridigBody组件 ，然后设置 group，碰到几十个不同的模型，怎么操作。
物理用这个方式设计是没问题的，但是得考虑用户使用，现在要加物理操作成本比之前高太多了
PhysX/Bullet 会默认加上刚体，这个没问题。但是做一些游戏只需要 Builtin 物理就行了，
因为只需要相互的碰撞信息和射线检测就能完成逻辑，不需要物理世界的模拟。要加 RidigBody组件去改Group 就不合理了，最后还得自己写脚本来设置group值。
为什么不像2D一样区分 碰撞组件 和 物理组件，这样可以给碰撞组件加Group 的选项，如果是物理组件就不加。
这个会在下个版本修复~