Grabbit 2 开发解析:在 Unity 编辑器中模拟物理
引言
我是 Will,Jungle(一组小型 Unity 工具)背后的独立开发者。我刚刚发布了 Grabbit 2,这是对一个插件的彻底重建,该插件自 2021 年以来一直允许游戏开发者使用物理在 Unity 中设计关卡和进行场景布置。下面来看看它是如何工作的、我第一次做错了什么,以及这次重建中改进了什么。

构想,以及为什么比听起来更难
Grabbit 会将你的选中对象放入编辑器内的实时物理模拟中。物体像在运行时一样由物理驱动,只不过这发生在编辑模式下,且无需为你选中的物体附加任何碰撞体或刚体。
完成后,Grabbit 会将结果写回你的变换(Transform)并清理一切。最后一部分比你可能预期的要棘手得多:
- 你必须在编辑时自行驱动 Unity 的物理世界,同时不干扰场景中的其余部分或项目的物理设置。
- 你必须为任意网格即时生成准确的碰撞,因为被放置的物体可能本身没有碰撞体。
- 你必须以非破坏性的方式完成这一切,这样如果任何环节出错,场景都能完全恢复原样。
- 在大型场景(1 万个或更多游戏对象)中,你仍然希望工具加载快、操作快:为所有网格创建碰撞体和刚体可能需要几秒钟。
Grabbit 是如何处理这些问题的?
Unity 允许你将物理切换到手动模式,在这种模式下没有物体会自行步进,而是由你掌控时钟。Grabbit 利用这一点,在编辑器时间内运行自己的模拟循环。当你抓取一个选中集时,两件事很重要:速度和隔离性。为了速度,Grabbit 2 会预分析你的场景,只拉取选中集附近的物体,因此无论场景变得多大,加载都会很快且保持快速(Grabbit 1 是一开始就加载所有内容)。
为了隔离,Grabbit 会禁用所有其他刚体,并在步进模拟前记住你的物理设置,随后在你完成时全部恢复,即使出现问题也是如此。你的其他物体永远不会移动,项目设置也会原封不动地恢复。

碰撞体很棘手
即时创建的碰撞体存在一个问题:PhysX 只允许凸碰撞体存在于动态物体上,因此一把椅子碰撞起来像楔子,一个甜甜圈碰撞起来像圆盘。这对于场景布置来说并不理想,因为其关键就在于物体能够可信地自然落稳。
Grabbit 通过凸分解(Convex Decomposition)解决了这一点:它将凹网格分解为多个凸片,这些凸片共同近似物体的真实形状。在 Grabbit 2 中,这一过程会在后台自动完成,因此不会出现可见的碰撞体烘焙等待时间。
它提供了三种碰撞体创建策略,你可以选择适合项目需求的那一种:
- Balance(平衡):使用快速的基于体素的分解。一个可靠的全面默认选项。
- Precision(精确):使用更新的、对碰撞感知的分解,在棘手的形状上能更好地保留凹面细节。
- Performance(性能):跳过分解,将简单图元(盒子、球体、胶囊体、圆柱体)拟合到网格上。模拟成本最低,而且通常简单的道具只需要这种即可。
当精确烘焙仍在进行时,Grabbit 会换用快速近似结果,因此你永远不会被卡住。




Grabbit 2 的新功能:为运行时烘焙碰撞体
一旦你生成了碰撞体,就有一个明显的下一步,而原版从未迈出这一步:让它们永久生效。在 Grabbit 2 中,你可以右键单击场景中的任何对象或预制体,在预制体模式下,或直接在项目窗口中,选择“烘焙凸碰撞体”(Bake Convex Colliders)。Grabbit 会将烘焙好的碰撞体写入该对象。
这些碰撞体会随你的构建一起发布,运行时无需任何 Grabbit 代码。你还可以在碰撞体库中浏览所有已烘焙的碰撞体。

第一次出错的地方,以及我修复了什么
Grabbit 1 能用,但从结构上看它是一个大约两千行的单一工具,并且具有你预期的那种有机成长起来的东西的失效模式。既然人们对构建这样的编辑器工具越来越感兴趣,诚实的经验教训可能是本文最有用的部分。
它可能留下一堆烂摊子。Grabbit 的整个模型是“添加临时物理、模拟、移除它”。如果编辑器在编辑过程中重新编译了你的脚本或崩溃了,该清理可能不会运行,留下杂散的 Rigidbody 或被改变的设置。Grabbit 2 记录了足够的状态来识别被中断的会话,并在下次加载时检测遗留的物理体并自动恢复你的对象。如果它漏掉了什么,还包含一键清理。
在大场景上变慢。没有空间结构,所以成本扩展得很糟糕。Grabbit 2 保持一个持久化的空间缓存,池化其临时碰撞体而不是每次抓取都分配,并行烘焙,并且只模拟靠近你选择的内容。
撤销不可靠。物理驱动的编辑正是你想要放心撤销的内容。在 Grabbit 2 中,每个更改都经过 Unity 的撤销系统,所以 Ctrl+Z 完全按你的预期工作。
它存在于编辑器窗口中,每次进入那个窗口都会把你从场景中拉出来。切换上下文耗费时间。Grabbit 2 与场景工具栏集成,因此你可以停靠它,一切都在上下文中。
这些都不光鲜,但它们是一个聪明的演示和一个你可以信任用于真实项目的工具之间的区别,也是为什么从头重建值得的原因。

五种模式:完整的关卡设计工具箱
交互侧被组织为五种模式,每种都是不同的移动对象方式,每一个都是原生的 Unity 编辑器工具,带有自己的 Scene View 覆盖层。每个快捷键都是真实的、可重绑定的 Unity 绑定,Space 是任何地方的主要操作。
- 选择(Select):在不触碰 Hierarchy 的情况下构建你的工作集:按体积、屏幕上的内容或当前选择来拾取,然后按相同网格、相似大小或共享的静止高度进行过滤。
- 创建(Create):从加权集合中生成道具,或复制你的选择,并让物理在它们落地时稳定下来。它可以沿直线、样条线、环形或体积放置副本。
- 放置(Place):主要模式:移动对象使其沿表面滑动并避免重叠,或通过你点击的精确点抓取对象,以精确放置椅子腿。
- 排列(Arrange):一键带来秩序:对齐到直线或曲线、平铺到共享平面、定向到共同框架,或通过推开重叠来修复碰撞,全部由 PhysX 驱动。
- 散落(Scatter):相反:随机化,从爆炸球向外爆炸,塞成一堆,或轻轻推动每个对象以产生细微变化,同样是物理驱动的。

可选的 AI 挂钩
对于在 Unity 内部使用 AI 助手的团队,Grabbit 2 可以选择通过开放的 Model Context Protocol(模型上下文协议)将其操作作为助手可以调用的工具公开。实际上,这意味着你可以要求你的助手放置或散落一组道具,并让 Grabbit 运行真正的物理操作并妥善稳定它们,而不是让助手猜测坐标。这完全是可选的:除非你自己安装了 MCP 主机,否则集成处于非活动状态,它仅限编辑器使用,并且不会给你的构建增加任何内容。

未来方向
我在构建 Jungle 的工具,但我首先是一名游戏开发者,我每天都用 Grabbit 来更快地构建自己的游戏。这就是它不断改进的诚实原因:我想要它为我服务。Grabbit 2 需要 Unity 6;Grabbit 1 仍然适用于 Unity 2022.3 及更高版本的项目。
如果你在 Unity 中做关卡设计,我希望你能试试它,并告诉我哪里不好。反馈造就了今天的 Grabbit!
有用链接:
- Asset Store。
- Discord。
- X/Bluesky: @shrubokrant
William Besnard,独立开发者
相关链接
原文链接:https://80.lv/articles/how-grabbit-2-simulates-physics-inside-the-unity-editor
喜欢这篇内容吗?