分开layer 和 group是没问题的，但是layer只要通过节点设置就好了，而物理 group 得通过组件设置（每次设置还得展开组件去改属性，操作麻烦。
而且有的 静态物体/不需要物理模拟的物体 只需要BoxCollider 碰撞盒，但是碰撞盒却不能通过编辑器设置 group/mask，代码里都是可以设置的，这增加了编辑的成本。
BoxCollider 可以设置 Group 的，只是得通过脚本来设置 collider.setGroup(group),你可以自己写个脚本代替RigidBody 设置值。（还有，其实你这个方式把 IsTrigger 勾上也不会有碰撞啊
1赞
我也觉得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 个渲染组可以设置，而对于大项目来说，且不说单场景可能会超过，多场景的情况下，可能用户希望用不同的意义来区分渲染组，比如- 室外地面和植被渲染组
- 室外建筑渲染组
- 室外特效渲染组
- 室内渲染组
- 角色渲染组
- UI 渲染组
尽可能多的 layer 设置，一定会让策划选择更轻松，不需要过多思考。如果组合上物理组，对渲染组数量的限制就会非常明显。
- 第二个原因很简单，我们不希望增加开发者在这个选择上的思维难度，因为物理和渲染本就是不同的，揉在一起 layer 的设置和选择都会变得更复杂。拆分开虽然设置操作比较多，但是绝对不会复杂，思考的维度是非常简单直接的。
除此之外就是建议参考 Unity 论坛中的吐槽，设计层面可能没有绝对的对错，更多是一种权衡和选择，对于这个问题我们仍然相信我们自己的设计是可以被开发者所接受的，我们也没必要硬靠友商的设计，更何况这是我们思考过利弊的选择。
目前我们建议是先设置好更完善的分组，在运行时随时切换 group 即可。当然你说的 API 也可以考虑
layer 是 Node 属性主要是因为渲染的级别确实比物理更高，所有游戏都需要渲染，渲染分组放在节点中是可以接受的（内部也在讨论是否要下放到 Renderable Component 内）。除非必要，我们一般是不会往 Node 上加属性，看上去方便，但是带来的长期技术枷锁是非常严重的，所以 group 就放到了物理组件中。至于 Collider 是否要允许在面板中直接设置 group 可以和 @JayceLai 讨论
感谢专业的回答，其实对于 group 的设置方式，我们做了很多方向的考虑
在节点上增加 group 属性
不使用的原因是我们不希望让节点增加过多的冗余数据，场景里面的物理节点毕竟还是少数
在碰撞体组件上增加 group 属性
不使用的原因有两个：
- Bullet 物理不支持逐形状 Filter，这也是我们目前使用单节点组合刚体的一个原因
- 目前单节点的架构中，Collider 附加到刚体上的唯一方式就是放到相同节点下，多个 Collider 时有冗余数据。而且由于不能设置为不同的（受底层不支持逐形状 Filter 限制），容易产生困惑
在综合考虑了以上方案之后，较优的方案是在刚体组件上增加 group 属性，以上所有的问题都可以避免
总得来说，目前很多上层不友好的使用和设计，还是受限于底层的基础设施不稳，我们也在计划优化这些东西
后续可能做的优化
未来我们会为 Bullet 后端增加逐 Shape Filter 的功能，在此基础上，还将重构为节点链组合刚体的架构，即时将带来以下功能：
- 允许每个碰撞体组件独立拥有和设置 group，不再受限于刚体组件
- 允许碰撞体组件带有本地旋转，极大的丰富基础形状的组合数量
除此之外，这个架构对编辑器内操作应该也是一个质的提升
刚体，刚体组件
其实市面上主流的物理引擎 PhysX / Bullet 的架构设计中，碰撞体都是必须附加到刚体中，刚体其实是必须的。
我们支持可以不加刚体组件，这并不是意味着没有刚体（内部其实会有个静态刚体）
我看材质的设置 是引用了材质，编辑器最底下就能直接编辑器材质。那么 只在属性检查器上增加一个group 属性设置 也是可以的吧，不一定数据上要放到 节点上，只要能方便编辑就行了。
现在编辑器内要搭建场景太难了。比如我拖一个模型到场景里，我就得手动加个 ridigBody组件 ，然后设置 group，碰到几十个不同的模型，怎么操作。
物理用这个方式设计是没问题的，但是得考虑用户使用，现在要加物理操作成本比之前高太多了
PhysX/Bullet 会默认加上刚体，这个没问题。但是做一些游戏只需要 Builtin 物理就行了，
因为只需要相互的碰撞信息和射线检测就能完成逻辑，不需要物理世界的模拟。要加 RidigBody组件去改Group 就不合理了，最后还得自己写脚本来设置group值。
为什么不像2D一样区分 碰撞组件 和 物理组件，这样可以给碰撞组件加Group 的选项，如果是物理组件就不加。
这个会在下个版本修复~
有一说一啊，我觉得对于程序员来讲：各司其职是一个比较好的设计思想。对于引擎应该也是，一个分组你一方面又要管渲染，一方面又要管碰撞，怎么看都会觉得怪怪的。
射线是任意层，之所以会检测失败，是因为配置的刚体掩码为0；下个版本会支持掩码为0，也能进行射线检测
目前你需要至少设置一个掩码，任意的都行，不要求是 default
我是说射线目前默认属于default层，如果敌人层enemy在编辑器物理设置面板里没有和default层设置为可互相碰撞的组，那么射线永远检测不到enemy的碰撞体。这种设定有坑，能不能修改，让射线自身不属于任何层，可以通过掩码和对应的层进行检测。
现在的射线不是什么任意层，而是默认给它加了个default层，导致检测受限