As a Roblox developer, it is currently too hard to work on mechanisms with complex self collision.
In this worst case scenario the constraints in the example image below were created dynamically.
The same problem was already fixed for weld constraints but for some reason the system to hide weld constraints wasn’t extended to no collision constraints when they were added.
I feel like collision groups would be a lot cleaner for something like that
Correct me if I’m wrong, but this isn’t how you’re supposed to be using NoCollisionConstraints? Like Preston said, collision groups would fit this task a lot better. In fact, the official documentation literally says “if you are trying to stop a large number of parts from colliding with another, it might be better to use Collision Groups.”
The issue with collision groups is that they cannot be used on the client. OP probably had to use these constraints due to this limitation.
By this, I mean you cannot create a collision group on the client.
Collision groups don’t do it for assemblies like vehicles. Key word: might be better, not is. Vehicles are one of the exact intended use cases of NoCollisionConstraints - it was one of the key examples in the feature announcement thread.
You have a limited number of collision groups allowed per experience and some physics features that you develop aren’t worth using an entire collision group. Additionally, cars can have any number of assemblies that you need to account for.
A complex structure of NoCollisionConstraints lets you preserve slots in the group limit for more important collision filtering, including on the entire car itself (e.g. vehicle exclusion zones require just toggling the collision of a vehicle group and not several vehicle groups).
They can. The client is only restricted from creating, deleting and modifying relationships between groups, but clients are still allowed to locally assign parts to a group, subject to override by the server.
This is what I was referring to. Having collision groups often makes your assembly non-portable, since collision groups are not self-contained in the model. Maybe OP needed to make this a package where the collision group ID was unfortunately not the same throughout the places it is used in.
If I have a collision group for the vehicle body and vehicle components (doors, wheels, loose hood, loose fender, etc), where:
…I fix all self collision problems but I lose the ability for components on different vehicles to collide with eachother, which is not what I want. If there were no limit I could create these two collision groups for each vehicle spawned in the game.
And for my use case I am dynamically creating the no collision constraints because I want it set up in a way where I can break off components and repair components on a vehicle. Because of this I can’t easily author no collision constraints between the exact self colliding parts as if it were a standalone model. I can improve the code so that less collision constraints are created though.
And back to the main topic:
Unlike welds, no collision visualizations tend to be unordered and chaotic. Visualization of a model dynamically welded together follows a tree-like structure while a visualization of two models that shouldn’t collide will show the collision constraint from every part in model A to every part in model B. A good reason for why no collision constraints need the ability to be hidden more than welds.
