Roblox Studio 碰撞组：设置并检查两个组

碰撞组控制什么 #

想象一条练习走廊：两支队伍推动不同颜色的箱子。不同队的箱子彼此穿过，同队箱子应发生碰撞，但两队都应被地板和墙挡住。这是虚构的教学场景，并非对已发布游戏的描述。

Collision Groups 为物理部件类别定义碰撞规则。无需逐一设置每对物体；把每个 BasePart 分配到一个组，再用矩阵指定组之间是否碰撞。组名本身不会改变行为，关键是部件分组和矩阵关系。

准备练习场景 #

从新的 Baseplate 或项目副本开始，并另存为单独文件。添加宽阔的 Anchored 地面、一面墙和两个小箱子部件，一个蓝色、一个橙色。箱子不要锚定，彼此留出距离并放在地面上方。先关注物理行为，不必装饰。

确认每个部件的 CanCollide = true。如果关闭，即使组对允许碰撞，该部件也不会提供通常的物理阻挡。箱子必须是 Part 或 MeshPart 等 BasePart，而不是文件夹或模型。组分配给部件；多部件模型要逐个检查相关部件。

先规划矩阵再分配部件 #

使用 BlueCrates 和 OrangeCrates 两个组。两个组都应与 Default 保持碰撞，只关闭练习组彼此之间的关系。每组放两个箱子，比较更容易观察。

矩阵表示组对关系，不是单向设置。A 与 B 的关系对两边都生效：若 BlueCrates 不与 OrangeCrates 碰撞，橙色箱子也会穿过蓝色箱子。组与自身的关系控制同组部件。若同队箱子应互相推动，就保持该关系开启。

在 Studio 编辑器中创建组 #

打开 Collision Groups 编辑器。Roblox 当前文档指出可从 Window > 3D 打开；不同 Studio 版本的面板名称或位置可能变化。如果编辑器提供世界选择器，请选 Workspace。通过 Add Group 添加唯一名称 BlueCrates 与 OrangeCrates。

编辑器默认包含 Default。所有部件最初都属于该组，它不能重命名或删除。确认两个新组出现在矩阵中，只关闭 BlueCrates/OrangeCrates 的交叉关系。若界面分别显示矩阵两侧的格子，请核对该组对状态。保存项目。

分配正确的 BasePart #

在 3D 视图中选中两个蓝色箱子，点击 BlueCrates 行的加号（⊕）分配它们。橙色箱子同理。面板具体外观取决于 Studio 版本。逐个选中箱子，在 Properties 中确认 CollisionGroup 名称。

分配到新组会使部件离开原组；一个部件同一时间只能属于一个碰撞组。展开模型检查所有物理部件，以免个别部件仍留在 Default。不要混淆 CollisionGroup 与 CanCollide：前者选择组规则，后者启用或关闭该部件的物理碰撞。

设置矩阵并理解对称关系 #

预期矩阵：BlueCrates ↔ BlueCrates 开启；OrangeCrates ↔ OrangeCrates 开启；BlueCrates ↔ OrangeCrates 关闭；两个练习组 ↔ Default 开启。开启表示在其他设置允许时该组对可以发生物理碰撞。关闭则表示部件会互相穿过，即使双方 CanCollide 都开启。

若只需排除两个特定部件之间的碰撞，Roblox 建议考虑 NoCollisionConstraint。规则适用于许多对象时，Collision Groups 更合适。不要为单个例外创建大量组。

打开大图 ↗

服务器脚本中的同一示例 #

若要了解脚本方式，在 ServerScriptService 中放置普通 Script，并在 Workspace 创建名为 BlueCrate 与 OrangeCrate 的部件。示例会注册缺失的组、设置关系并分配部件：

当前 API 在 Workspace/WorldRoot 上记录了 RegisterCollisionGroup、IsCollisionGroupRegistered 和 CollisionGroupSetCollidable。创建组及更改关系必须在服务器端执行。项目中通常可先在 Studio 编辑器设置组；Roblox 指出注册会产生少量开销，且开销与 Workspace 部件数量有关。新示例不要使用已弃用的 PhysicsService:CreateCollisionGroup() 或 SetPartCollisionGroup()；当前 PhysicsService 参考将其标记为弃用，并指向 Workspace 管理方式。

这段简短代码只分配两个独立部件。它不会处理模型或角色的所有部件；扩展实现需遍历后代并分配每个 BasePart。实例名称必须与 Explorer 一致。

local workspace = game:GetService("Workspace")
local blueName = "BlueCrates"
local orangeName = "OrangeCrates"

for _, name in {blueName, orangeName} do
    if not workspace:IsCollisionGroupRegistered(name) then
        workspace:RegisterCollisionGroup(name)
    end
end

workspace:CollisionGroupSetCollidable(blueName, blueName, true)
workspace:CollisionGroupSetCollidable(orangeName, orangeName, true)
workspace:CollisionGroupSetCollidable(blueName, "Default", true)
workspace:CollisionGroupSetCollidable(orangeName, "Default", true)
workspace:CollisionGroupSetCollidable(blueName, orangeName, false)
workspace.BlueCrate.CollisionGroup = blueName
workspace.OrangeCrate.CollisionGroup = orangeName

在单独运行中检查行为 #

保存场景，然后使用会启动模拟的 Studio 运行模式，例如 Play。以下是测试计划，并非本文已执行的测试：Studio 没有启动，也没有观察物理结果。

摆放蓝色和橙色箱子使其相遇；组对关闭时，预期彼此穿过。蓝色撞蓝色、橙色撞橙色应当发生碰撞。每个箱子都应被 Default 组中的地面和墙壁挡住。停止模拟，只开启 Blue/Orange 关系，再运行并比较这一组对。每次比较前确认起始位置和 CanCollide。

自行运行后记录实际结果。一次本地模拟不能证明所有网络场景或设备上的行为。

每次运行只检查一对箱子。将下方箱子放在地板上，上方箱子放在它正上方，留出空隙；两个箱子都保持未锚定。启动模拟后，上方箱子落向下方箱子。同组预期相互接触；不同颜色之间关闭碰撞时，预期穿过。随后启用不同颜色之间的碰撞，保持同样摆放再运行。检查墙壁时，将箱子放在墙边，用角色推动；另外检查地板。运行后填写实际观察，不要把预期结果直接当成已验证的结论。

打开大图 ↗

排查意外结果 #

若两种颜色仍相撞，依次检查：两个部件是否确实分属不同组；矩阵关系是否关闭；检查的是否为刚刚编辑的同一个 Workspace。然后检查 CanCollide，并确认模型没有部件留在 Default。

若箱子穿过地面，检查其组与 Default 的关系，以及箱子和地面的 CanCollide。若脚本报告未知组，可能是注册没有运行或名称拼写不同。CollisionGroupSetCollidable 遇到未注册组会报错，因此示例先检查并注册。

Touched 事件是另一回事：Roblox 文档说明它可能在 CanCollide 关闭时仍触发。不要只用触碰事件证明物理阻挡有效。

记录观察并继续 #

保存所选矩阵、部件分配清单和简短记录：已检查的组对、预期行为与实际观察。如果更改矩阵，重新检查受影响的组对，包括与 Default 的碰撞。

下一步可以尝试在模型加入时给所有部件分配组、测试角色，或把组规则与 NoCollisionConstraint 对比。每种扩展都要单独检查。当你能从矩阵预测结果，并在 Studio 运行中确认时，本练习目标就完成了。