New constraint and CanCollideWith API change

Hello Devs!

Today we released a new, simple, constraint. It’s called… * drumroll *…

The NoCollisionConstraint.

It lets you connect two parts so that they don’t physically collide with each other, but they still collide with everything else. And like the WeldConstraint, it doesn’t use Attachments. You can find it with the other Constraints in the Model Tab > Constraints > Create dropdown menu.


Isn’t this just what collision groups do?
Kinda. And if you have big groups of part collisions you want to filter, you should still use Collision Groups.

But the big difference with the NoCollisionConstraint, is that it is an Instance in the Explorer tree. This means you can create, publish, and download models with customized collision filtering. You can quickly remove problematic contacts in your complex physics models or NPCs. (Excess contacts can slow performance!)

Here the NoCollisionConstraint is being used to prevent the car’s wheels from colliding with the body.

The ragdoll on the left is using some NoCollisionsConstrinats to prevent unwanted collisions in the waist. Red dots show collision contact points.

UPDATE 8/7/2019
This also lead to a small change to the BasePart:CanCollideWith API. This function will now return false for parts connected by a NoCollisionConstraint, as well as other constraints that prevent collisions between parts, like HingeConstraint and BallSocketConstraint.
It didn’t use to do that, before even if two hinged parts weren’t colliding, that function would return true. Now it returns false.

That’s it! Please let us know here if you run into any issues.


A post was merged out – Please do not post entirely unrelated bug reports and feature requests here, use Platform Feedback for that. This post is about a physics-related change.

Would this be affected if one or both parts are Anchored while they are connected?
In a case where the parts would later be no longer anchored and/or can collide with one another in some way.

Some humor



If one or both parts are anchored, canCollideWith should still return false if they are connected by a NoCollisionConstraint. This is the same behavior as if they were in different collision groups that don’t collide, or one part has canCollide=false.

1 Like

Thank you for this! Do these work well with other constraints such as prismatic and hinge constraints?


Yep! Combining all kinds of constraints together is encouraged! Though you shouldn’t need this with a hinge, since a HingeConstraint already prevents collisions between two parts.


I have an odd question that I’m not 100% will be phrased correctly but I’m going to try here anyways. Assume we have three parts: A, B, and C. A and B are in two collision groups that are set to not collide with each other but will still collide with the rest of the world, C has the default collision group. If A and C were to be connected via this new constraint, would C now be nocollide respective to B or would it still collide with B?


This makes making ragdoll, vechiles, and anything that relys on collisions so much easier. Thanks to the team who pushed this out.


The true question is, can I have that beautiful ragdoll script?


C would still collide with B in this case; this constraint doesn’t affect Collision Groups at all.


So in other words this is a Collision Management Feature for non Scriptures.

Awesome, Now I don’t have to do everything! :+1:t2:


Yesterday here’s me thinking that Roblox won’t be getting a new constraint for me to add to my constraint GUI. Today, this releases :joy:. This seems awesome though and could really open up new opportunities for things like one way doors and platforms.


This will be very useful for ragdoll, or just messing around with it with stop motion or something, I could imagine. Thanks for the constraint update!


In the car example, what was the setup of the wheels? I feel like the constraint is being used to disable collisions between an entire assembly and the main body of the car.

A welcome update though. I’ll most likely still be using CollisionGroups more than this, but it’ll help immensely in cases where I need to filter collisions without using up CG space.


This seems like it will be very useful, seems like I need to get to work on learning how to fully utilize it.


Thanks for adding this! I didn’t realize how useful it would be until I ran into a problem with vehicles that were made for Roblox’s old physics solver. Now I don’t need to waste collision groups to fix them :slight_smile:


This new function will greatly help a project I’m working on

1 Like

Can we get one of theses in reverse as well?

Such as a part is CanCollide = false, but with say CollisionConstraint (Instead of NoCollisionConstraint) we can have those two parts collide, but every foreign part will not collide?

Sounds a lot like Collision Groups, but this would also be exportable as a model as well as NoCollisionConstraint. Interesting things to think about🤔


Does this constraint use up some of your collision group count? I don’t imagine it would since there could potentially be more than 32 in a game but just checking.


This looks really neat, I’d have to mess around with this sometime, it looks extremely handy to have.

1 Like