Help How does one disable "phase" based collision masking?

[Hatchling]

I'd like to ensure that, in my project, everything is able to collide with everything else. However, each time I instantiate a rope, it has the same phase as the last rope I instantiated.

I'd like to disable this feature, as going in and editing each rope I instantiate to have a unique phase seems like it'd be a real pain.

Is there a way to do this? Or would I need to modify source code I don't have access to (e.g. in the DLL)?

EDIT: It appears that using self-collision doesn't just allow collision with the self, but also allows collision between *everything else* of the same phase, *except* rigidbodies, which mostly solves the problem: Just make sure everything has "Self Collision" enabled and that every particle actor uses phase 1, and every rigidbody uses phase 0.
The description is a bit misleading. (Also, as a side note, the term "phase" doesn't evoke the concept of collision. Usually phase is used to describe something's progress through a cycle, like rotation. Perhaps "layer" would be a better term.)

[josemendez]

I'd like to ensure that, in my project, everything is able to collide with everything else. However, each time I instantiate a rope, it has the same phase as the last rope I instantiated.

I'd like to disable this feature, as going in and editing each rope I instantiate to have a unique phase seems like it'd be a real pain.

You can write a simple script that bumps the phase value for each instance. I can share some code if you wish.

Is there a way to do this? Or would I need to modify source code I don't have access to (e.g. in the DLL)?

The full source code for the Burst backend is included and you can modify it to your liking, it is recommended to use it instead of the fallback backend (Oni) which is a shared library indeed. Burst has broader platform compatibility and slightly better performance in some cases.

EDIT: It appears that using self-collision doesn't just allow collision with the self, but also allows collision between *everything else* of the same phase, *except* rigidbodies, which mostly solves the problem: Just make sure everything has "Self Collision" enabled and that every particle actor uses phase 1, and every rigidbody uses phase 0.

This won't work. Self-collisions will ignore collisions against particles in the same rest position, so particle #3 in different actors instantiated from the same blueprint won't collide with each other. You might get lucky in some cases, but this is not a robust approach.

The description is a bit misleading. (Also, as a side note, the term "phase" doesn't evoke the concept of collision. Usually phase is used to describe something's progress through a cycle, like rotation. Perhaps "layer" would be a better term.)

"Phase" as in state of matter phase. This is a standard term in physics. Other particle-based engines such as Flex use the same term, so we didn't want to reinvent the wheel. This also avoids confusion since Unity already uses the term "layer" with a different meaning.

[josemendez]

Just finished implementing mask-based collision filtering, which completely replaces phases.

Now each particle (and each collider) has an additional 32 bit integer associated to it. The 16 less significant bits are used to place the particle in one of 16 possible “categories”. The 16 most significant bits are a mask that let you specify which categories should the particle collide against.

So you can specify a “Category” value (0-15) and a “Collides with” mask, for each particle in an actor, and for each collider.

The phase value is now repurposed as a unique “actor id”. Particles with the same actor id (that is, belonging to the same actor) collide with each other only if the actor has self-collisions enabled. Otherwise, the category/mask is used.


- By default, everything collides with everything else (in the same solver). No need to manually bump phase values for each actor to collide with other actors.

- Works for cases that weren’t possible before. You can have actor A collide with collider A’, and actor B collide with collider B’, but have B not colliding with A’ and A not colliding with B’.

- Self collisions are actual self collisions, not collisions with things in the same phase.

This is scheduled for release in Obi 6.2, around a month from now.

[Hatchling]

Just finished implementing mask-based collision filtering, which completely replaces phases.

Now each particle (and each collider) has an additional 32 bit integer associated to it. The 16 less significant bits are used to place the particle in one of 16 possible “categories”. The 16 most significant bits are a mask that let you specify which categories should the particle collide against.

So you can specify a “Category” value (0-15) and a “Collides with” mask, for each particle in an actor, and for each collider.

The phase value is now repurposed as a unique “actor id”. Particles with the same actor id (that is, belonging to the same actor) collide with each other only if the actor has self-collisions enabled. Otherwise, the category/mask is used.


- By default, everything collides with everything else. No need to manually bump phase values for each actor to collide with other actors.

- Works for cases that weren’t possible before. You can have actor A collide with collider A’, and actor B collide with collider B’, but B wont collide with A’ and A won’t collide with B’.

- Self collisions are actual self collisions, not collisions with things in the same phase.

This is scheduled for release in Obi 6.2, around a month from now.

Wow, that's a big change. I appreciate the rapid response to feedback (even if this was already a planned change)! 

[josemendez]

Wow, that's a big change. I appreciate the rapid response to feedback (even if this was already a planned change)! 

This thread sparked it, so you’re -almost- entirely responsible for this change .

Thought about it for a while and it just made sense to do it this way. No performance penalty, it’s just a bitwise “and” between category and mask to determine whether to collide or not.

[josemendez]

Here's how it looks/works. This scene has two ropes and two colliders. Each rope can only collide with one of the colliders. Also, both ropes collide with each other.
The colliders have a "category" and a "collides with" mask:



Same for rope control points:


The first rope is set to category 0, and can collide with everything.
The second rope is set to category 1, and can collide with everything.
The first collider can only collide with category 0 (the first rope).
The second collider can only collide with category 1 (the second rope).

[Hatchling]

I'm guessing this largely mirrors what Unity's collision matrix does, except it doesn't use Unity's layers.

I like this. One thing I wish Unity did differently was to de-couple collision layers from rendering layers (which, afaik, are the two main/only features that use layers). Often I've found the need to split up the limited 32 layers between things that are relevant to rendering and things that are relevant to collision. If a game object had both a renderer and a collider and needed to be organized into two separate layers, you'd need to split the game object up instead. Often it is easy to just assign a whole prefab to a layer for its collision and wind up with Unity complaining about renderers being on more than 4 layers.

Good thing that won't be a concern here.