Godot: "Collision Groups" handling Collision Layers & Masks

[ivanskodje]

This is an ongoing idea that I am building on, and I believe this have the potential to simplify collision layers and masks - for intermediate and beginners alike.

While I was working on a tutorial explaining Collision Layers and Masks thoroughly, I realize that a lot of the work consists of having to manage and setting up the individual collision layers and masks.

While I realize we have a "Groups" tab that allows us to set groups, it does not directly affect collision layers and masks without going into gdscript of each object and managing collisions from there.
You could argue that you could check which group "I am on" and set layers and masks from code - and I am sure that would work, but that is not simple or effective - at least not compared to this possible solution.

For example, when working with layers and masks I usually plan ahead of what types of objects will be in which layers and interact with which masks. This is an example of my note:

Collision Layers | Masks
1 - Static Objects (immovable objects, floor, roof, etc.) <-> 2, 3, 4
2 - Friendly Rigid Bodies (crates, player, etc.) <-> 1, 2, 3, 5
3 - Enemy Rigid Bodies <-> 1, 2, 4
4 - Player Bullets <-> 1, 3
5 - Enemy Bullets <-> 1, 2

I realize that keeping this consistent can be incredibly awkward. Having to go back to my list every time I create new objects.
After all, for every, single, object I make; I would have to go into the inspector and manually set individual layers and masks.

So this idea hit me; Why not create a "Collision Group" system, that allows us to setup individual collision groups for those masks and layers?

Imagine having an simple drop down menu in place of Collision Layers and Masks that allows you to set a new Group or choose an existing group.
When creating a new group, you set a name for it and select which layer it is on and what it with collide with (masks).
Some of the best advantages with this, is that if you later decide that all static objects should also collide with objects on layer 6, you just edit the group instead of doing inside every single object and manually adding 6 to them.

Group name: "Static Objects" <---- This is what you set on new objects that are static
Layer: 1
Mask: 2,3,4

Group name: "Friendly Rigid Bodies" <---- Easy setup of friendly rigidbodies such as player, crates, etc.
Layer: 2
Mask: 1,2,3,5

_Lastly I should add_; you should not be forced to setup a group - you should still be able to just directly set layers and masks without defining a group.

Thoughts? Feelings? Any flaws that I have not foreseen about this? ;)

[eon-s]

I like the idea, and add to this the new named layers, the group setup could be a lot more user friendly.

This could be made with a plugin too, a panel to set the groups and add selected node to a group.

[Zylann]

What about creating a new Resource type PhysicMaterial that you can reference on PhysicObjects? It would do all of what you ask, though it needs to be created indeed.

Otherwise you can already do all this by using scene inheritance/composition (but as always with inheritance it's not covering all usages).

[aaronmzn]

_bump_ Yes, I was thinking of something like this too, but instead of combining it with Layers/Masks it should replace it. Yeah it would need some changes of how collisions works but as long as Group Collision exists, Layers/Masks will not be needed because it will be easier to manage and straightforward for new users.

I'll explain how I have it in mind, because I don't think I'm in the same page as @ivanskodje

Lets say on a platformer game you have 5 objects and you add them to certain groups as you would do normally:

• Player is on "player" group
• Block is on "solids" group
• IceBlock is on "solids" "Ice_blocks" groups
• SafeBlock on "barrier" group
• Enemy is on "baddies" and "solids" groups

At this point nothing is colliding with anything so you HAVE to set them to a group in order to set it to collide with something later. I don't know if this helps performance but its seems like it should too, no idea. anyway...

if you want a certain body to collide with something you have to set it to collide with a group or multiple groups, ex:

• Player will collide with "solids" group (Block, IceBlock, Enemy)
• Enemy will collide with "solids" and "barrier" group (Block, IceBlock, SafeBlock, Enemy)

you set it on the UI as you said with a drop-down list BUT instead you can select multiple groups with a checkmark at the side of the group name, on script you could set it with something like _set_collision_with("solids")_. would be cool if this function had arrays support so you can do something like _Enemy.set_collision_with(["solids","barrier"]) and set collisions with a single line of code.

if you want the Player/Enemy to act differently with an IceBlock then you can check with something that already exists: _get_collider().is_in_group("ice_blocks")_ if the Block is touching is in the "ice_blocks" group, if its true then this will make the Player/Enemy slide around when touching these IceBlocks (same if player is touching something in the "baddies" group). This also can be seen as a sort of _PhysicMaterial_

now, for example, since Block is not set to collide with any group this mean Block will not collide with anything and can't check what is colliding with it, so its just there, but as long as its there, then Player and Enemy will have something to collide with, Blocks can have values in a script so other Scenes can get values from the Blocks though.

again this would require to change how collisions works a little bit but I don't know, Collision Layers & Masks works but I don't think they are a good way of managing collisions, but thats me.

[KoBeWi]

3.1 introduced a convenient dropdown menu with layer names. While you still have to manually check every bit, it's easier to label them and know what to click.

Would that be enough to resolve this issue, or a proper "groups" are a must-have?

[akien-mga]

I think we can consider this solved by named layers.

If more is needed, please open a new proposal on godot-proposals.