Godot-proposals: Rename `Rect2` to `Rect` (and considerations regarding consistency with `AABB` name in 3D)

[Xrayez]

Describe the project you are working on:
Godot Engine. 🙂
This proposal builds upon discussion in #1528.

Describe the problem or limitation you are having in your project:
The problem with AABB and Rect2 currently is that they don't convey the same meaning out of the box (no pun intended!).
AABB suggests "bounds", but Rect2 has only geometrical meaning encoded in its name.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Why Rect2 is not just Rect? Consistency with Vector2 and other similar structures? See https://github.com/godotengine/godot-proposals/issues/1528#issuecomment-695200323. To demonstrate, there's a reason why Quat is not Quat4. The digit encoding only makes sense for those Vector2/3 types.

I suggest that those structures should only convey geometrical meanings to achieve better consistency and generality, rather than possible use cases which may be specific. For instance, think about AABB usage for selecting and manipulating parts of a GridMap where cells are already axis-aligned by definition, and where the position and the end properties would be used for initial and final cell positions instead.

That said, I'd rename AABB to Box3, or just Box if we also rename Rect2 to Rect. The Box name wouldn't conflict with anything. At most, there's only BoxShape collision shape resource.

As pointed out in https://github.com/godotengine/godot-proposals/issues/1528#issuecomment-695442738, the Box terminology is also used by Unreal Engine in core.

The AABB icon could be greatly simplified if we rename this. Look how clunky it is currently:

There's simply not enough space, and looks more like musical notations like "C sharp" or "D flat" because of that! 😅

The visual problem is more apparent on smaller screens. Also compare with Rect2:

See? Even the icon itself suggests the rename.

If you think that AABB still encodes important information that it's axis-aligned, think about Rect2. In either case, we have a problem, which is only feasible to resolve via documentation that both classes are axis-aligned.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Just rename all occurrences. In scripts, it would look like:

var aabb: Box = mesh.get_aabb()
var bounds: Rect = $Sprite.get_rect()

In Godot 4.0, there's also Rect2i which should be renamed to Recti

Similarly, another issue I see with current AABB is lack of AABBi for specifying 3D region via integer coordinates as with the mentioned GridMap and alike. As a funny bonus, if we do rename this, then it would become Boxi. 😄

Note that the API itself don't have to be changed (and likely must not), because the method names and documentation convey the use cases. But those structures themselves can/should be agnostic to a particular use case.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Certainly, just use current names, there's no way around it.

Is there a reason why this should be core and not an add-on in the asset library?:
It's totally possible to make a plugin which can provide aliases and various other utility methods for manipulating core data structures, like with VectorResource plugin.

As for me, just renaming Rect2 to Rect would also be enough to resolve this proposal as I'm mostly working with 2D projects personally, yet it would be wrong not to do a similar treatment for AABB, because the issue is likely with lack of consistency here, as seen in #1528.

[KoBeWi]

That said, I'd rename AABB to Box3, or just Box if we also rename Rect2 to Rect. The Box name wouldn't conflict with anything. At most, there's only BoxShape collision shape resource.

Rect and RectangleShape is a similar case, so it would be good for consistency.

[clayjohn]

I agree on Rect2 -> Rect. But I think Box doesn't convey enough information. I think it is very important that the name convey that it is a special type of object that expands to encapsulate another object. If we are to rename AABB, I prefer BoundingBox.

I actually prefer "Bounds" but apparently Unity uses bounds quite differently than our AABB do it may cause confusion https://github.com/godotengine/godot-proposals/issues/1528#issuecomment-696452411

[Xrayez]

AABB documentation:

Axis-Aligned Bounding Box.
Rect2 consists of a position, a size, and several utility functions. It is typically used for fast overlap tests.

Rect2 documentation:

2D axis-aligned bounding box.
Rect2 consists of a position, a size, and several utility functions. It is typically used for fast overlap tests.

API-wise and documentation-wise, these classes are mostly very similar, but somehow Rect2 is not AABB2D nor AABR!

I can only speculate on this though, because I'm not proficient in 3D. Nonetheless, perhaps the documentation is wrong.

If we are to rename AABB, I prefer BoundingBox.

Then Rect2 should be BoundingRect? But Rect2 is currently used for more than just encapsulation of other objects/geometry, talking about "Region" rather than "Bounds" (see CanvasItem.draw_texture_rect_region). Similar logic could apply for AABB, but now the name is reserved for "Bounds" rather than "Region", unlike with Rect2 which doesn't discriminate neither of these concepts currently.

I know it's difficult to break the "industry standard" but I think what I say makes perfect sense in relation to Godot.

That's why I'm kind of insisting on abstracting away all those "bounding", "region", "axis-aligned", "containment" concepts, and focus on pure elementary geometry aspect instead, which is more prevalent in basic math, because simplicity is probably the core principle behind Godot development. Those are rather implementation details, as someone would say.

If I want to use a Box as axis-aligned one, that's cool. If I want to use it just to define a region in 3D, that should be fine as well. The documentation can properly define the scope so that contributors won't attempt to make it do something for which a class wasn't designed to do, like #1529.

[clayjohn]

@Xrayez I mostly agree with you! AABB is impossible for users to understand without reading the documentation, so it would be nice to have something more descriptive and more accessible.

However, an AABB is very different from a BoxShape due to both its implementation and use. I am concerned that calling it a box without any qualifiers will lead to more confusion than sticking with a more complex name.

I guess at the end of the day it's a balance of who is going to be confused. Should we simplify the name so that it is no longer clear how the AABB is different from other Box primitives, or do we use a more complex name that may be less initiative for users not versed in geometry? I think both have pros and cons.

[Shadowblitz16]

I think renaming rect2 to aabb2 and aabb to aabb3 would be fine.
at least that way people can learn what a aabb is and not have to search for the 2d or 3d equivalent to each other.

I honestly think box is more confusing then rect because a box can be rotated a rectangle is usually not rotated.
the only issue with rect is that some people don't like the name rect3, as they argue its no longer a rectangle but a cube.

[Jummit]

I just want to mention that Rect2 is not used as a "Axis Aligned Bounding Box" very often.

[reduz]

They are fine as they are, they are not used for the same things in most situations, so its perfectly valid they convey different meanings. Them having similar naming would be worse.

[Xrayez]

@reduz what about Rect2 → Rect though? The only logic I can think of which can explain the current Rect2 name is that it allows to define "two endpoints" for a rectangle, like with Rect2(Vector2, Vector2) constructor (yet the second parameter is for size, not bottom-right endpoint).

Or perhaps because it's Rect2D, without a D. 😃

[Shadowblitz16]

@reduz I disagree they may not be used for the same thing, but they are the same thing.
one is just 2d and the other is 3d.
from experience I know that with different names they are confusing.

one might say ok I need a axis aligned bounding box or a rect and then realize they need the 2d/3d equivalent and are not able to find it in the docs due to naming differences.

you might say: then why don't we just add that info to the docs?
I would say: that might reduce the confusability alot but why do they have diffrent names in the first place when they are the same thing?

why can't we have a rect2 and rect3 or a aabb2 and a aabb3 and have both uses in mind with similar implementation?

[Xrayez]

why can't we have a rect2 and rect3 or a aabb2 and a aabb3 and have both uses in mind with similar implementation?

Also, have to be careful adding extra classes, because they will need to be handled by various Variant operations. Alas, stubbornness wins with AABB case. 😛

[Xrayez]

I'll close this to prevent renaming existing classes to something more verbose than the current state of art, still open for discussion!