CollisionGroups Subgroups can't collide with themselves.

[DennisSmolek]

I was trying to do something similar to the alternate filtering demo but I'm having a hard time...

What I want, is boxes that are in a group. Lets call it "Red Group". These boxes should collide with each other like normal.

A platform that acts as a safe pass through. Where ONLY red boxes are allowed through. This is like a trapdoor.

If I put the Red Group and the trapdoor in the same ColliderGroup the trapdoor functions, however the boxes DONT collide with each other.

So what I tried to do, is have the boxes in a subgroup (lets say group 1) and the trapdoor in another subgroup (group 3).

I DISABLE collision between subGroup 1 and subGroup 3 so they fall through the trapdoor.

I ENABLE collision between subGroup 1 and subGroup 1 so they collide with each other.

The Trapdoor works as expected, the boxes fall through. However, the Boxes do not collide with each other no matter what I do.

Is there no way to have a subgroup collide with itself?

---

I have a live codesandbox HERE
And you can see it just running live here

All objects (besides the floor) are using the same CollisionGroup and are set in GroupID 0.

The Blue platform is acting as the trapdoor I explained and is in subGroup 3.

The Red platform is in the same subgroup as the boxes (subgroup1). The boxes should collide with this layer.

The yellow platform is another subGroup but without explicit collision settings. It correctly collides.

[jrouwe]

The GroupFilterTable never allows a sub group to collide with the same sub group:

https://github.com/jrouwe/JoltPhysics/blob/cca9c4ad170aff8119632ea8763474f1b20f8d54/Jolt/Physics/Collision/GroupFilterTable.h#L30

/// * 'x' means sub group 1 == sub group 2 and we define this to never collide.

I would use collision layers instead through e.g. the ObjectLayerPairFilterTable, these allow defining if a layer collides with itself or not.

Alternatively you can write your own GroupFilter implementation by extending GroupFilterJS and defining the logic in the way you want, something like:

let filter = new Jolt.GroupFilterJS();
filter.CanCollide = (group1, group2) => {
	let g1 = Jolt.wrapPointer(group1, Jolt.CollisionGroup);
	let g2 = Jolt.wrapPointer(group2, Jolt.CollisionGroup);
	return !(g1.GetSubGroupID() == 1 && g2.GetSubGroupID() == 3) && !(g1.GetSubGroupID() == 3 && g2.GetSubGroupID() == 1);
};

(warning totally untested code)

[DennisSmolek]

Interesting ok!

I'd like to try more with ObjectLayers but it's hard to do in a more universal library because the JoltInterface can only be set once initialized and it requires you to know how many ObjectLayers you have.
For now I just have one for static, dynamic, and kinematic objects.
Later I'll rewrite the initialization so layers can be made dynamically before starting.

Unless there's a way to change the ObjectVsBroadPhaseLayer filter and bpInterface at runtime?

I forget sometimes I can override the canColide function, that'll totally be useful.

[LeXXik]

In my library, I do allow setting those up at initialization. Users already give some configuration options. Layers is just one of them. There is also an alternative way to do collision filtering, using bitwise masks, similar to Ammo's groups/masks. You would still need to do it before you create Jolt Interface, though, so at initialization time.

https://github.com/jrouwe/JoltPhysics.js/blob/main/Examples/alternative_collision_filtering.html

[DennisSmolek]

Yeah I saw that version too.
I'm pretty happy with my customized groupFilter for the moment however at some point I'll have to add layers to the options.

[jrouwe]

Unless there's a way to change the ObjectVsBroadPhaseLayer filter and bpInterface at runtime?

You could probably create your own ObjectVsBroadPhaseLayerFilterJS, BroadPhaseLayerInterfaceJS and ObjectLayerPairFilterJS and change their behavior at run time. Beware though that the number of broadphase layers needs to be known at initialization time and can't change. Also, once you add a body to the world, you cannot change anything of the (broadphase)layer it is in.

[DennisSmolek]

I think the approach I would take would be to save the state of the current running system and create a new one from scratch with the new layers then try to restore the state. That or something like it.
I think a user of the library would be making those kind of changes before doing anything major, so there would likely be no bodies in the system yet so maybe nothing even to save/restore.

It's mostly my internal states/classes that would break and need to be remade, which is doable.