Updates to Collision Groups

Hi Developers,

We updated the Collision Groups Editor with a new UI, a fresh coat of paint, and also added a new property, CollisionGroup[string], to BasePart for the collision group name.

Overview of Changes

Editor Changes and improvements:

  • You can view collision states in the traditional table view or as a list per group.
  • The UI no longer has duplicate edit and buttons on each row.
  • Adding multiple collision groups at a time now require no extra clicks. All you need to do is type a name, press enter, and repeat.
  • Double-click group names on the left to rename them, or select a group and press the rename icon at the top.
  • Delete groups by selecting a group and pressing the delete button at the top.

New Property for Collision Group Name:

  • The new property CollisionGroup[string] replaces the CollisionGroupId[int].
  • No change is needed for the existing CollisionGroupId. The default value for the new property is “Default“. Internally, the engine respects the CollisionGroupId if the new property has a “Default“ value. We encourage you to use the CollisionGroup[string] in the future.
  • The CollisionGroup property allows the collision group to be more portable between places. With the new CollisionGroup, as long as the collision group name is the same in two places, copying a model from one place will preserve the same collision rule in another place after pasting the model into it.
  • We introduce a few new APIs in PhysicsService along with the CollisionGroup[string] property.
  • We will deprecate the CollisionGroupId[int] along with some old APIs in PhysicsService.
  • Please note the behavior of PhysicsService:RenameCollisionGroup will be different if you start using the CollisionGroup[string]. The API will only rename the registered CollisionGroup[string]. It will not rename the BasePart CollisionGroup[string] in the Workspace.

How to Use

To open the Collision Group Editor, navigate to the Model tab, find the Advanced section, then click the icon for Collision Group Editor.

In the Explorer window, the new property is under BasePart.

Next Steps

  • The Editor will roll out around the same time as this announcement.

  • The Collision Group Name will roll out a few days later.

  • Are there plans to remove or deprecate anything?

    GetCollisionGroupId: To be deprecated
    GetCollisionGroupName: To be deprecated
    CreateCollisionGroup: To be deprecated. Replaced by RegisterCollisionGroup

    RemoveCollisionGroup: To be deprecated. Replaced by UnregisterCollisionGroup

    GetCollisionGroups: To be deprecated. Replaced by GetRegisteredCollisionGroups

    SetPartCollisionGroup: To be deprecated. Replaced by calling BasePart.CollisionGroup

    CollisionGroupContainsPart: To be deprecated. Replaced by calling BasePart.CollisionGroup

We’d like to invite everyone to see if their development experience is improved by these changes and provide their feedback.

@PotionSeller33 & @APandaPoet


This topic was automatically opened after 11 minutes.

This is an interesting update, and I’m actually not quite sure what to say. Definitely like that improvements are being made, but:

A. Does this improve performance from before, or decrease lag?

Anywho, generally, interesting…

(i just removed a question, that was dumb smh)


I’m really glad collision groups are being revisited & polished further for better UX! Out of curiosity though, is there a better way to detect whether a collision group exists as of now? :GetCollisionGroupId errors if none is found, so I’m forced to do as such at the moment:

if not pcall(function()
end) then

For one of my projects I’m forced to do such a hacky workaround because of this function erroring and such. Really hoping there’s a solution to this, I’d not I hope roblox will reconsider.

Because of how the game works, it allows any other maps to load in and create this collision group or mess with my check to see if it’s already created. I am forced to do this because of how these functions behave if none are found or trying to create a collision group that already exists, causing the game to break.

Really hoping these inconsistencies are fixed


THANKS YOU, I always had problems in my games, and in which it helped because I had to re-assign CG to to the parts.



What is a collisiongroup? never heard of them


Great update, but is there any plans on increasing the collision groups limit from 32 to something higher?


I was not a fan of the quite verbose and inconvenient to type API of PhysicsService, so I’m really happy the API for collision groups is being streamlined.

New collision group editor also looks great and way more functional, so kudos!


in short, makes that some objects can collide with some but not with others, a kind of collision filtering.



Yes. This is something we are considering.


Very nice QoL update! This will definitely make working with Collision Groups easier! :slight_smile:


Finally collision groups are getting some attention, although I prefer creating them via script, the new property will be useful and will allow programmers to quickly assign collision groups without calling PhysicsService

@PotionSeller33 Will the deprecated APIs spit a warning to the console (but still work)? Mainly asking since my game likely makes use of some of these deprecated APIs & properties, but I cannot update to using the new ones right away.

If the deprecated ones are still functional, what’s the timeframe until they lose their functionality?


This is an AMAZING QoL update. Basically addresses all of my concerns with Collision Groups. Better portability, and much more intuitive methods of setting/getting Collision Groups.

Glad to see the UI getting an update as well!


Generally deprecated on a Lua API does not mean that it will “lose it’s functionality”. The purpose of depreciating a Lua API is:

  1. Letting you know that the API may not work properly alongside other new features added after it was deprecated.

  2. Letting you know that there’s a newer better API available.

We value backwards compatibility, and that doesn’t end when an API becomes deprecated. Deprecated APIs MAY be removed or stop functioning at some point, but generally only after quite a long time and only if they actually become hard to maintain thanks to other newer engine changes. If we eventually do need to break a deprecated API it’s not a decision we take lightly.


Got it, thank you for the response!

Will the deprecated APIs in this instance spit warnings to the console?

1 Like

No, AFAIK, not in the near future.


Really like this change.

I don’t quite understand the point of this change.

I think it’s because you can input the name of a nonexistent collision group into the CollisonGroup property, but it won’t do anything.

So, unregistered groups kinda exist, but don’t work.

1 Like