Improving UI for Collision Masks and Layers

[BaddRadish]

DISCLAIMER:

So I know I might get some push back on this because "its the way we've always done it", which is not an unreasonable argument in general. Change requires a lot of mental energy. But I implore you to take a moment to consider this idea, because I'm confident that I'm at least on the right track here.

PREMISE:

As it stands now, masks and layers are based on numbers. "Mask 2", "Layer 4", etc. This is legitimately unintuitive and cumbersome. Its an added and unnecessary burden to make devs memorize which entities are on which layers. Almost unavoidably, devs must create an entirely mental schema for what each layer ultimately represents - maybe a layer for monsters, one for platforms, one for the avatar, etc. As it stands, there is no built in way to assist devs with this. This is equivalent to not commenting your code, which as we all know is a legitimate problem.

This leads to the percolation of an entire class of bugs, where some entity gets stuck on the wrong layer, or masked with a layer its not supposed to be masked with. While these bugs are trivial to fix, they can be hard to spot and troubleshoot, and can in some cases cause serious problems.

It would be trivial to associate each numbered layer with a dev-defined string which would serve as a name/label for the layer. This would improve readability, comprehension, intuition, etc. Yes those bugs would still occur, but far less frequently and would be easier to spot when troubleshooting.

Note this is not a new idea. This is a common and recurring problem/pattern in programming in general - we start with codes for say machines instructions, errors, etc, which again are unintuitive and cumbersome for the same reasons. These are later replaced by strings for the UI. We should lean on the insights of the past and follow this pattern to its logical conclusion. I believe its godot's inevitable fate to implement something along these lines, its just a matter of the specifics and when this happens. We as a community or those contributing code may choose to delay or be clever about this and do something totally different, but I do believe this should at least be looked at for godot4.

IMPLEMENTATION:

Under the hood, very little would need to change. These names could be as simple as a string->int lookup table, with each string being given a different number.

1. We would need to replace the current number interface (where we have a 16 check boxes which expands to 32 check boxes) with something that focuses more on what the dev is actually using. Very rarely will a dev need exactly 16 layers. We could display a scrolling list of all /defined/ labels with a checkbox for each. This list would grow as the user defines more layers. Maybe the dev could pin and/or sort the labels so they dont need to open the drop down each time they want to configure an entity.

2. A button with the ability to add a new named layer would be needed.

3. We would need a way to rename layers. Renaming would be trivial, since the string is basically a comment.

4. We would need a way to delete layers. Deletion would admittedly require a bit more work, since we would really need to uncheck that mask or layer on everything using it. I believe this is a feature we already need to have to avoid bugs, since the dev's mental schema may change and the user would then have to manually update every entity to reflect the new schema. Almost certainly they'll miss one or two.

5. We would need a way to access renaming/deleting layers. It could be as simple as right clicking a label to pop up a rename/delete menu, but then we have a context within a context, which I think some people will have mixed feelings about.

6. This lookup table could be made available in scripting as well, to resolve any issues on that side of things. A function that uses a lookup table or hash to turn a string into the appropriate int would suffice.

7. Obviously there's still the hard 32 limit, but I don't think this needs to be part of the UI so much as the spec. We /would/ need to warn users when they add each new layer or the 33rd layer that there's a hard limit of 32 layers. Thats trivial. Obviously we need to have it in the documentation, which I'm assuming it already is in. And obviously we need a simple mechanism to prevent devs from creating a 33rd label.

At this point, devs would never even need to know about the underlying number interface. They would only interact with the names, which I believe would be a huge improvement. By this logic, I would highly suggest we /hide/ the ints from the devs completely, and have them work directly with this label interface instead. Its safer and just better across the board. However for some devs in particular cases, it would be a bit slower if a user needed to change the mask/layer of thousands of entities each frame. Perhaps the ability to store the looked up int for reuse would solve this issue and prevent any real performance concerns here. So the scripting interface would be its own function that returns a layer id number or something like that.

Migrating devs over to this system would be a little bit tricky. Perhaps we could initialize all 64 layers on older projects with a number for the name, and then they could rename or delete them to get the desired results? I'm not sure what we can do for migration, which is why I wanted to bring this up for godot4. Maybe we can add an optional manual int field that allows us to capture a specific layer number and name it, so that projects can be safely migrated. I mean the checks are still there since we didn't change the underlying implementation. We just have layers that aren't yet named with contents on them. So I'm not sure but I believe we can work out the kinks here.

Again, this is not a change to any physics code. This is merely a way for users to work with the mask and layer numbers more intuitively in the UI. At compile time or whatever, it trivially goes right back to what we have now, just under the hood. So we wouldn't need a physics expert to resolve this issue.

Thus, implementing this change would almost certainly be very reasonable, as its built on top of existing systems rather than trying to replace them.

CLOSING STATEMENT:

Because of the potential for intuitive code, the removal of bugs, and the relative ease of implementing this feature, I would strongly suggest we make this change to godot's interface.

Thank you for taking the time to consider this idea.

PS:

While we're reconsidering the mask/layer interface, we may also consider changing the language used from masks/layers to something more intuitive, like "collides as" and "collides with". I found this a bit strange to work with at first and had to explain it in detail to assist another dev at one point.

But this is unrelated to my other suggestion, and I don't feel strongly about this change. The current language is good enough, and not even necessarily the source of confusion. It may just be a bit abstract as a system, which is fine.

[Zireael07]

Related to #3930

[snw-0]

As noted in #3930, layers can already be given names via the Project Settings, but I don't believe there's any indication of this functionality anywhere else, and the names you set only show up in a few places in the UI. Adding more ways to edit the names and/or exposing them in more places could be useful.

[BaddRadish]

it would be awesome if we had a way to show these names as a list in the panel instead of just a grid of numbers. in fact its insane that we dont. like hover over a random guess number and wait for the name to pop up to figure out if its the one you think it is isnt really the best solution here.

code as well. like theres got to already be a string->int function for that, right?? if not, why the heck not lol.

id also love it if we could delete a layer automatically instead of having to manually uncheck anything. this isnt my main concern here though.

[miv391]

it would be awesome if we had a way to show these names as a list in the panel instead of just a grid of numbers.

You can see the names in a list. Click the "..." button in the right and a list opens.

Sure it would be nice if there were an editor/project setting for showing either the layer bit grid or layer name grid.

[wareya]

There are three constraints on the current design: one, the system is just nothing but bit flips under the surface, for important performance reasons; two, presenting it as an arbitrarily-long list would present a problem with how to deal with deletions, like, do you go in and alter all of the code and saved scene data that has it stored as bits instead of layer names?; and three, space taken up in the UI.

Two ideas that don't attempt to break these constraints:

One, what if right clicking a layer in the node inspector brought up a dialogue to rename that layer?

Two, a possible compromise on the UI: expanding the layer button list could turn it into the named list that you currently get with the ... menu button. It could still maybe be multiple columns to save vertical space. Or it could perhaps only display named layers (with their bit numbers), with a button to open up the layer name manager in the project settings at the bottom.