Introducing the StudioSelectable Collision Group

Hi Creators,

Today, we are solving an existing pain point with selection mechanics in Studio, and introducing additional selection filtering capabilities while we’re at it.

Problem: Collision with Default

If you’ve ever assigned a collision group that does not collide with the Default group to some parts while editing your place, you’ll know that this comes with the side-effect of those parts not being selectable by clicking in the viewport in Studio. This usually isn’t what you intended.

The reason for this was that when doing a raycast to find out what object is under your cursor, Studio tooling used to leave the collision group filter of that raycast set to Default. The result was that anything which doesn’t collide with Default would be invisible to that raycast and not end up getting selected.

Solution: New StudioSelectable convention

As a solution, we’re introducing a new convention in Roblox studio. All Studio tooling will use the collision group StudioSelectable when doing selection raycasts.

This accomplishes two things:

  • You’re now free to disable collision with the Default collision group as you see fit for gameplay purposes without it impacting Studio editing behavior.

  • You can configure the StudioSelectable group to control what objects in your experience are candidates for viewport selection.

The Collision Groups Editor has some dedicated tweaks for working with this group. Under the hood there’s no special engine support for this group, it’s just a normal collision group like any other, but by standardizing on this convention we get extra value out of the existing collision group system.

For example, you can now assign a CollisionVolumes collision group to all of your collision volume parts, allowing you to quickly toggle between editing map geometry and collision volumes.

Plugin Users: Some plugins require an update

If you use one of the following plugins, install the most recent plugin update to avoid breakage:

  • Team Create with Hats
  • StudioTweaks
  • Seat Preview!
How to install a plugin update

In Roblox Studio, under the Plugins ribbon bar tab click the Manage Plugins button at the left, and click the Update All button, or the individual update buttons for the plugins you wish to update. Any plugins you’ve set to auto-update will already have installed the update.

While this change is mostly backwards compatible, the above plugins create collision groups which do not collide with Default as a way to mark some parts as not selectable. We’ve worked with the authors of these plugins to ensure that they interact correctly with the StudioSelectable group after their most recent update.

Also be on the lookout for other plugins updating to support the new selection filtering mechanics.

Plugin Authors: How to update your plugins

If you’re a plugin author, please consider updating your plugins to follow this convention! When following the convention, those plugins can take advantage of the new selection filtering mechanic and avoid unintended collision group behavior.

Since there are no underlying engine changes your plugin will continue to function as it did before even without an update (with the exception of the ignoring selection use case which we contacted affected devs about ahead of time), but it only takes a small change to get the benefits.

To update your code, set the collision group on the RaycastParams passed to your cursor raycasts:

local raycastParams =

-- Add this collision group convention.
raycastParams.CollisionGroup = “StudioSelectable”

-- Note: You should also use BruteForceAllSlow if you want
-- your plugin to be able to select CanQuery = false parts.
raycastParams.BruteForceAllSlow = true

local mouseTarget = workspace:Raycast(..., raycastParams)

Please let us know if you have any questions.

Thank you.


Additional Details / FAQ

Do I need to have the Dragger QoL Beta enabled to get this?

  • No, you’ll see this change whether or not you have the QoL Beta enabled, though if you haven’t checked it out in a while you should go check out the beta again as we’ve made significant updates to it recently.

Do I have to use the Collision Groups Editor to configure selectability?

  • Since this is a convention we’d like to get adoption started as soon as possible. In the future we can offer other more convenient Studio controls to configure the underlying collision group. You could even implement a plugin that configures it today.

Should I do this on all my raycasts?

  • No. Only the raycast your tooling does to find what’s under the cursor or similar should use StudioSelectable.

Should my cursor raycast in-experience use this?

  • Probably not. However, you do have that option if you want the same selection behavior for an in-experience editor as you have in Studio. But chances are you still want to use Default or your existing raycast group in-experience.

But I already have a group called StudioSelectable!

  • What are the odds…? Regardless, we’ve got you covered! You can rename that group to something else in the Collision Groups Editor to preserve the setup you had and get a fresh StudioSelectable group.

I already have 32 collision groups… what now?

  • Don’t worry! Under the hood, the StudioSelectable collision group is only created the first time you configure it in the collision group editor. That means your experience with 32 collision groups will continue to function, but you won’t be able to configure selectability until you free up space for the StudioSelectable group to be created.

Won’t raycasting code error if the StudioSelectable group doesn’t exist?

  • Yes, raycasting used to throw an error if the group did not exist. That behavior has also been changed.

    Now if you raycast or region query with a group that does not exist you’ll get the same behavior as a part with a group that doesn’t exist - The nonexistent group will be treated as colliding with everything. That means the code will work as intended even in legacy places where the StudioSelectable group has not been created.


This topic was automatically opened after 10 minutes.

all I have to say is, YES YES YESSS!!! studio selections has been a pain especially for things like selecting objects inside of other objects or objects with broken collisions. Can’t wait to see this in action!


i don’t know what that means but cool :+1:t2:

also why does streamingenabled cause things to stop rendering when the player character is destroyed


I made a lasso select tool last year however I used my own 2D raycast algorithm to detect parts that are overlapping inside the polygon, I’m wondering if I need to change anything in my code to respect this change?

Right now I’m just iterating over the workspace to find overlapping parts by position (probably a little expensive but whatever).


Beautiful quality of life update
not a huge fan of it being under a collision group, but I’ll gladly take it nonetheless


I wish those collisions had some special number or a separate collision group type that we could not create ourselves.

Can we get a warning instead of nothing? It won’t break code, but will let developer know that something may be wrong.

Is there a specific reason why there is only 32 collisions available? I’m assuming it’s because it fits into a particular data type that may be the most efficient for the game engine to go through at high frequency.


This also opens the door to decoupling the Locked property in Studio from gameplay functionality, as this technically unlocks the ability to enable or disable categories of selectable parts. Very happy to see this change made in this way.


This has given me the horrible reminder that studio is pretty much just the roblox client with more features


Thank GOD this was added! This actually makes building in studio a lot less frustrating now!


What is it used for and what does this mean? I want to make sure I’m not missing out.


So the most important question I have is how many people this actually applies to lol. Good on you guys for making sure to account for this scenario no matter how unlikely it may seem though!


The previously existing error was hit basically never, so a warning doesn’t seem necessary.

The advantage of not having a warning is that it’s possible to set raycastParams.CollisionGroup = part.CollisionGroup in plugin code and not have to worry about whether the part’s collision group actually exists.

You don’t have to, it would be possible though.

If you’re using a call that takes OverlapParams, that also supports collision group filtering, and even if you aren’t, you can manually check CollisionGroupsAreCollidable as part of your search.


Once upon a time, you could even literally edit your game by playing it solo inside the normal Roblox client! So it kinda makes sense, in a way.


Yes, this is implementation details leaking. Allowing an unbounded number of collision groups has been investigated but you would not want to use a particularly large number regardless if you want to stay on the engine’s fast-path so we haven’t shipped that yet.


This is, while a fair bit overdue, a much welcomed change. And I’m all for it!


Very nice and welcome change to studio. I like how this feature is simple enough and doesn’t require major changes on the plugin side to take advantage of. Was able to add only a couple lines and everything works. Please continue to add QOL changes like this!


Why make a new collision group when you can just do RaycastParams.CollisionGroup = "" which would make your raycast collide with everything and then just manually filtering if something is supposed to be selected or not?


That would solve solve one of the problems but introduce a new one by completely taking away the ability for users or code to make things not selectable. Including breaking the plugins mentioned in the post.

Having a dedicated way in the ecosystem to know when someone is trying to select things or not and be able to key off of that in tooling is useful.


I noticed this issue with collision groups, but I never imagined there being an update for it that is going to address it. Very cool.