godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.15k stars 97 forks source link

All confusion from Collision Layer eradicated via a simple label rename. #3032

Closed BracerJack closed 3 years ago

BracerJack commented 3 years ago

aaaaaaa

YuriSizov commented 3 years ago

Please follow the proposal template, your issue will be reopened when you do.

I understand that you think you suggest something extremely simple and not worthy of a formal proposal, but we have to keep standards. Plus you still have some message added to describe your proposal in there, albeit it is hidden in the picture. So please move it from the picture to the proper text and fill out the sections provided. An image is a good aid though.

Keep in mind that sections in the inspector are named after the properties, and changing a display name like that may dissociate it from the property it is setting and make it harder to work with.

See also https://github.com/godotengine/godot-proposals/issues/2770.

golddotasksquestions commented 3 years ago

The problem already starts with this being called a "Layer". There is nothing layer like to it. You can't stack it, there is no vertical or horizontal relationship in a "collision layer". No onions, no ogre. It's just a group.

The concept of layers and masks make a lot of sense in digital imaging software, like Photoshop. Like in a painting, you lay on layer on top of another.

Collision Layers in Godot however are not laid on top of each other. They don't have any vertical relationship.

"Masks" is also incredibly unfortunate naming as a mask in a system of layers is the area that is blacked out - the area that does not count to the end result. It's in the name "Mask" - Like something you put in front of your face. Only where there is no mask, you can see through. Only the area that is not masked counts. Same goes for "masking tape". You tape off with masking tape whatever should not be taken into account. This is how it works in photography, in construction, in film, in painting, in costume design, in figurative speech ... everywhere, except in Godot.

In Godot does the opposite: Whatever you check as "masked" is there. Is counted. Is the relevant part.

The most mind boggling part here is that what collision masks do has nothing to do with masking anyway. When you check a masking bit, you are actually telling Godot to check for collisions with nodes in this group. You are not masking anything. If anything you do the reverse.

Instead of "Collision Layer", it should be called "Collision Groups", Instead of "Collision Mask", it should just say something along "Checks collision with:"

collision_layers_naming

insomniacUNDERSCORElemon commented 3 years ago

@golddotasksquestions what about collision set and collision get?

Maybe even collider would be a bit more logical as well.

golddotasksquestions commented 3 years ago

@insomniacUNDERSCORElemon I think almost anything would be better than "collision layer and masks". But "Collision set" and "collision get" is not really explicit either. It also sounds like methods (we actually already have get and set methods).

I think it needs to be very clear how the upper grid is for assigning this very object to Collision Group(s), while the lower grid is for telling the Object which Collision Groups it should checks for collisions.

cptchuckles commented 3 years ago

@golddotasksquestions

In Godot does the opposite: Whatever you check as "masked" is there. Is counted. Is the relevant part.

As it is in a thing like a bitmask and an alpha mask: values of 1 are counted, 0 is not. This makes sense from both a CS and digital art standpoint.

Now that is not to say this is the most clear way to represent things, I can see how such a usage of this word is niche. I also have a hard time defending Godot's choice of the word Layer, which I believe was inspired by Blender's pre-2.8 visibility layers, and supported by Unity's convention of "Layer Collision Matrix". blender_render_layers unity_layer_collision_matrix By contrast, Unreal's Collision Filter system uses terms like Object Type and Collision Response, which I think are much more ergonomic unreal_collision_filters

I favor the latter greatly, now that I think about it. Perhaps we could rename them like this LayerCollider Type MaskCollision Responses

BracerJack commented 3 years ago

I Love @golddotasksquestions "checks for collisions with", it just makes so much sense. Thank you all for your support in the matter !

YuriSizov commented 3 years ago

@golddotasksquestions We can't just rename the label, the property itself needs to be renamed (if that's even a problem). And "check collisions with" it probably not the best property name.

Either way, your analysis and further discussion here is a very good basis for a proposal, so feel free to open one, since this one doesn't seem to be getting fixed.

Dwapook commented 3 years ago

collision write and collision read has been clear to me in the past.. and write/read are simple names..

AaronRecord commented 3 years ago

This change would probably only be relevant to 3.x btw as this behavior is being reworked in 4.0 https://github.com/godotengine/godot-proposals/issues/2775

AttackButton commented 2 years ago

Other problem is the wrong representation of the two way collision (like 3.x) in the editor, layers and masks create just a link between the two objects, but the editor incorrectly just shows one side, even though the engine makes the collision correctly.

The confusion starts when the user set in an object the mask to collide with another object, both will collide correctly, but visually on the editor the last one not necessary will need the first checked in it masks as well.

The solution for this could be the editor to automatically check the mask of the second object with the layer of the first one.

Every time the mask of one is checked, the editor could check on the mask of the other as well.

That's what the unity layers collision matrix do somehow. It's ugly, but very effective to show the link between the objects:

image

Zireael07 commented 2 years ago

@AttackButton: Your idea would've made sense some time ago. Now it doesn't, as in 4.0 A can collide/detect B without the reverse being true, so it doesn't make sense to tick the other's mask too.