Add an AABBi type

[groud]

Describe the project you are working on

A voxel-based game

Describe the problem or limitation you are having in your project

In our voxel-based game, working with 3D volumes is difficult. Selection areas, zones occupied by a "big tile", areas of effects, etc... need to be computed using a position and size tuple with Vector3i types.
Their manipulation can be difficult (unlike it is with the AABB type, though that one uses float values). Functions AABB provides like abs(), grow() or accessors like end would be quite useful in an Integer-based sapce.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Similar to what we have in 2D with Rect2i, it would be quite handy in the 3D space to have a type to represent a 3D integer volume.
This can be useful for any kind of grid-based 3D games, but it's a also a generic useful data structure.

Internally, I suppose the GridMap API could also be modified to make use of such a new type (maybe VoxelGI too I'm not sure?)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

We would add the AABBi type. Which would be AABB but with Integers, or Recti but in 3D.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I guess a AABBi extending Object type could be created using a script, but it would not provide the same ease of use as built-in types.

Is there a reason why this should be core and not an add-on in the asset library?

I guess similarly to Rect2i for Rect2, the AABBi counterpart of AABB should most likely be core.
And it would be easier to use as a built-in Variant type.

[Zylann]

I made my own Box3i in my voxel engine: https://github.com/Zylann/godot_voxel/blob/master/util/math/box3i.h
And yes it is really useful to encapsulate a lot of things when operating on voxels.

That said... even if Godot gets AABBi I think I will keep mine because it got a lot of functions that suit my needs very well, and Godot might not have the same requirements for having them (like stricter conversions, step conversions, lambda iterations or lambda difference). It was already a bumpy ride using Godot's Vector3i instead of mine, as Godot is missing tons of things I use a lot in my module, and does other things I did not want like implicit conversions from float vectors (I still did the change cuz they had the same name, were not namespaced, and was the least ugly thing I could do at the time).

[groud]

That said... even if Godot gets AABBi I think I will keep mine because it got a lot of functions that suit my needs very well, and Godot might not have the same requirements for having them (like stricter conversions, step conversions, lambda iterations or lambda difference). It was already a bumpy ride using Godot's Vector3i instead of mine, as Godot is missing tons of things I use a lot in my module (I still did the change cuz they had the same name, were not namespaced, and was the least ugly thing I could do at the time).

I guess that if you implemented yours, there's not a lot of point in switching indeed. I guess for the features that could be missing, users would probably implement helper function instead, that would take the AABBi as arguments. (Those function don't necessarily need to be inside the AABBi class)

[Zylann]

Yeah true. I did that with Vector3i, I needed all these https://github.com/Zylann/godot_voxel/blob/ed5bca22c7c1fd60ad3695f649792a90f6972901/util/math/vector3i.h#L271

[Xrayez]

I made my own Box3i

See also #1671:

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.

I recall there was a discussion at Matrix chat, where @bojidar-bg (who used to actively contribute to Godot development) was also in favor of adding AABBi type, but reduz was against it some years ago, therefore consensus might be blocked.

See also godotengine/godot#36436 where Rect2i was added by reduz, but not AABBi.

[caimantilla]

I'm working on a grid-based dungeon crawler, with a 3D world. Vector3i works well for grid coordinates, but I was disappointed to find out that, despite integer structs being added in Godot 4 with Vector2i, Vector3i, Vector4i, and Rect2i, there's no such love for 3D regions. I feel that AABBi should be added, if for nothing else but parity with Vector2i and Rect2i.
I was apprehensive about the subject before, as I've seen resistance to adding Variant types due to slight performance costs. However, PackedVector4Array was added recently, which seems like an even more niche use case than AABBi. If PackedVector4Array is okay, why not AABBi? Would there be any issue adding AABBi if I made a PR implementing it?