Expanding WorldModel Simulation Capabilities: Support for Collision Groups

[m0bsterlobster (mobsterlobster)]

We’re currently investigating an issue with Collision Groups Editor updates. To prevent further errors while we work on a fix, we have temporarily disabled WorldModel collision group management in the Editor. We appreciate your patience and will re-enable it as soon as it’s bug-free!

---

Key Takeaways

We’re taking the first step toward per-world simulation control on Roblox by moving collision group management from PhysicsService to WorldRoot and therefore supporting collision groups in WorldModels.

PhysicsService is now deprecated in favor of these updated APIs.

---

Hi Creators,

Today, we’re taking the first step toward expanding simulation capabilities in WorldModel to support true per-world simulation control.

Our long-term goal for WorldModel is to transform it into an independent, parallel physics sandbox, opening the door to full physics simulation inside ViewportFrame GUIs and giving you more control over multi-world simulation.

To kick this off, collision group management is moving from PhysicsService to WorldRoot.

This change brings two key improvements:

• Per-World Isolation: Each WorldModel instance can now maintain its own independent collision group state or inherit from Workspace when desired.
• Consistent Physics Queries: Spatial and physics queries, such as Raycast, GetPartBoundsInBox, and CanCollideWith, inside a WorldModel now fully respect collision groups, bringing WorldModel behavior into alignment with Workspace.

What’s Changing?

Collision Group Management Moves to WorldRoot

Every collision group management method that lived on PhysicsService is now available directly on WorldRoot. Because Workspace and WorldModel both inherit from WorldRoot, each world instance now gets its own independent budget of 32 collision groups.

Since managing collision groups was the primary responsibility of PhysicsService, PhysicsService is now deprecated in favor of these per-world WorldRoot APIs. In the table below, see which APIs are deprecated and what APIs replace them.

API Mapping

Before (deprecated)	After (canonical)
PhysicsService:CollisionGroupsAreCollidable()	WorldRoot:CollisionGroupsAreCollidable()
PhysicsService:CollisionGroupSetCollidable()	WorldRoot:CollisionGroupSetCollidable()
PhysicsService:GetMaxCollisionGroups()	WorldRoot:GetMaxCollisionGroups()
PhysicsService:GetRegisteredCollisionGroups()	WorldRoot:GetRegisteredCollisionGroups()
PhysicsService:IsCollisionGroupRegistered()	WorldRoot:IsCollisionGroupRegistered()
PhysicsService:RegisterCollisionGroup()	WorldRoot:RegisterCollisionGroup()
PhysicsService:RenameCollisionGroup()	WorldRoot:RenameCollisionGroup()
PhysicsService:UnregisterCollisionGroup()	WorldRoot:UnregisterCollisionGroup()

New Property: WorldModel.UseWorkspaceCollisionGroups

To make setup effortless when you don’t need distinct collision rules per world, we’ve added a new boolean property: WorldModel.UseWorkspaceCollisionGroups.

• False (Default): Simulation and spatial queries resolve against the WorldModel’s own independent collision groups.
• True: Simulation and spatial queries inside the WorldModel resolve using Workspace’s collision groups instead, removing the need to duplicate setup logic across worlds.

Note: Reading or writing WorldModel collision groups while UseWorkspaceCollisionGroups = true will issue a Studio warning, as that specific world’s state is currently bypassed.

Touch Behavior on WorldModel

All touch detection in WorldModel now inherently respects collision groups (matching the behavior of Workspace.TouchesUseCollisionGroups = true). This is non-configurable on WorldModel, aligning with our long-term goal of making all touch events respect collision groups across all worlds.

Backwards Compatibility

These changes are fully backwards-compatible:

• No code changes required: Existing calls to PhysicsService will automatically forward to Workspace.
• Zero breakage for existing worlds: WorldModel.UseWorkspaceCollisionGroups defaults to false, preserving existing query setups.
• Identical method behavior: WorldRoot methods behave identically to their old PhysicsService counterparts, with the only change being which world instance owns the state.

Studio Collision Groups Editor Update

To complement these API changes, we’re updating the Collision Groups Editor in Studio!

• World Selector Dropdown: When your place contains at least one WorldModel, a dropdown appears at the top of the editor letting you inspect and modify the collision group matrix for any specific world.
• Inheritance Checkbox: An inline “Use Workspace Collision Groups” toggle lets you sync a WorldModel to Workspace rules with a single click.

What’s Next?

This is the first step toward expanding simulation capabilities in WorldModels to support more advanced per-world workflows. Looking ahead, we’re exploring next steps to expand WorldModel simulation capabilities to better match Workspace, as well as enhancing creator control over simulation in general. This includes exploring:

• Full physics simulation inside WorldModel
• Global simulation rate adjustments (enabling effects like slow-motion physics) on WorldRoot
• Exposing scriptable physics stepping on WorldRoot

We’d love to hear which of these capabilities or workflows you are most excited to see in the future! Thank you for your continued support, and please feel free to share your feedback, report any issues, or show off what you’re building with this new WorldModel feature in the comments below.

Happy Building,

Roblox Physics Team

[MightBeKohl (Kohl)]

Very curious what this means for server authority, all the maps in our game are client rendered and the server keeps a copy in its camera so it’s not replicated, and terrain never loads, so this creates issues with server authority for us

Will these new upcoming world model changes possibly make this work under server authority?

Server Authority - Tech Deep Dive + Engineering Insights

I’m not sure how I should handle this issue with server authority in my game, as in our game we load all the maps for each ongoing game in the sky in the camera on the server, and then the players load their own copy of the map on their client The problem with this is that as there is multiple maps overlapping when multiple games are ongoing at the same time, it causes issues with collisions with server authority: [image] We also don’t load terrain for maps on the server, and instead only lo…

[Extuls]

These changes are huge and I definitely find them very exciting. Will there ever be a feature, either through this or some other means, which helps us create different worlds players can teleport between within a single server? The current solution is generally to just put areas far away from each other, and while it’s possible to make this appear seamless and perfect to players, the actual intention is to move between areas and make other areas completely non-existent on screen.

The future changes mentioned sound very close, but not exactly the same. Perhaps what I’m asking for is going to essentially be covered by the upcoming streaming disabled feature in the roadmap, but I don’t know much about that and don’t think it would play nice in server authority with two worlds trying to put things in the same space.

[stuart2202]

I’m very happy to see more control over physics being handed to devs, I hope to see more along these lines!

I also noticed references to things like “GravityDirection” which is exciting.

[Razorter]

It’s all coming together…

@Razorter

My simple solution to this is for an instance similar to WorldRoot to be implemented which would only simulate physics of descendants beneath it. And then you would have multiple of these instances be the “root” of your levels such that physics in each level are simulated idependently from one another.

[PysephDEV (Pyseph)]

Hi! Our studio has been running into severe performance degradations related to WorldModels; the root cause is we have an inventory of upto 400 items, each one being animated with a WorldModel.

We already employ virtualization and only render WorldModels on-screen, however that itself is the bottleneck – WorldModels still get evaluated even when parented under an invisible frame (or even ScreenGui), which means the only way to stop updating WorldModels that aren’t on-screen is to parent them to-and-fro nil… but given our high-fidelity models that are animated, just a single Parent operation can cost 2-4ms! And when scrolling an inventory grid, you end up having to parent 10-20 WorldModels at a time, which cause huge lag spikes.

This is currently unavoidable because there is no workaround for this. My request would be: could we please gain a IsSimulating property, or have the ability to effectively set the simulation rate to 0 Hz? This would eliminate all our performance issues, letting us virtualize WorldModels without the expensive parenting

[HealthyKarl]

I don’t know, if I have ever seen a game use a ViewportFrame with a WorldModel, just to do physics in it.

So, I am not sure why physics simulation inside WorldModel. Also because ViewportFrame has a resolution cap.

But if this is about WorldModel while under Workspace, with different physics, then maybe that sounds interesting, but idk if that’s what it is for.

[me7474 (74゠゠゠゠゠74)]

@m0bsterlobster

Exposing scriptable physics stepping on WorldRoot

this is massive!!! This should allow for all sorts of cool stuff, off the top of my head custom rollback netcode. I know server authority is a relatively new feature but there is currently a lot of edge cases where the netcode falls flat or is too bandwidth intensive. The ability to write game specific rollbacking should it be needed is awesome!

[wallofgarlic (garlic)]

Are you guys exploring the idea of being able to have multiple workspaces with different players in each ?

[Tavikron (Octav)]

@m0bsterlobster

UseWorkspaceCollisionGroups

So this means we won’t have multiple workspaces in the future?

[BastonGeneral (Latouffe95)]

Roblox !!! Youve been cooking with these updates lately.

The thing that would make me really happy would be seeing server authority allow more freedom regarding “invalid attributes” andd methods that allows terrain to be modified in scripts

[shadowflame63 (MiniiMann)]

I like the direction this is going in, really looking forward to getting better access to how physics runs. Also convenient to call the functions directly through the WorldModel, those kind of changes are nice.

I’ve wondered for a while what determines the collision group limit of 32 (now per WorldModel), and if it would be possible to push it a bit further or if this is a hard limit.

[me7474 (74゠゠゠゠゠74)]

shouldn’t you be able to simulate this with one workspace? You can create a new copy of anything you want to be server replicated on player join and then destroy those instances on all other clients. What usecase makes true separated workspaces necessary?

[SwitchedDreams]

Speaking of Collisions, are there any plans to fix Precise fidelity to actually be a 1:1 collision model of the mesh?

[SaturnianNightmare (SaturianNightmare)]

I’m glad to see this happening!

Could we also possibly see support for lights and shading in viewport frames?
I think it’s one of the biggest things holding back viewport frames. currently.

[Xarcian (edward)]

Suggestion:
Add PhysicsSimulationSource and AnimationSimulationSource property and a manual StepPhysics(deltaTime) and StepAnimation(deltaTime) method to WorldRoot

• PhysicsSimulationSource: WorldRoot? : points to another WorldRoot to inherit its physics tick from (defaults to Workspace). Setting it to nil stops automatic physics stepping
• AnimationSimulationSource: WorldRoot? : ditto of PhysicsSimulationSource but for animation
• StepPhysics(deltaTime): Manually drives physics
• StepAnimation(deltaTime): manually drives animation

Would let devs run isolated client prediction and rollback, and custom netcode architectures at custom frequencies without hacking around RunService, Additionally setting the simulationSource(s) to nil allows you to completely freeze physics, collision processing, and animation updates for entire model heirarchies in place enabling efficient culling and lod management without heavy perf overhead of nil parenting

[BastonGeneral (Latouffe95)]

Yesss now make particles work in vp frames

[Yal_f (yal)]

this isn’t how collision fidelity works. collision during physics simulation and how a mesh is rendered is calculated completely differently, roblox doesnt ensure a perfect match between the two for optimisation and contact response accuracy reasons. if PreciseConvexDecomposition doesnt give you enough accuracy (which in 99% of cases it would), you could split the mesh up manually.

[TenebrisNoctua (Noctua)]

The Roblox Engine would benefit significantly from a singleton that is used everywhere that needs physics simulation, including Workspace. WorldModel feels almost like a singleton, but it isn’t given how there is still behavioral and capability differences between it and Workspace. Workspace and WorldModel should share a better inheritance tree that makes them fit in this singleton model.