Geometry: Arch

[avdstaaij]

The geometry and vector_tools modules could use an arch function.

[avdstaaij]

Possible function signature (based on https://en.wikipedia.org/wiki/Arch):

def archRound(corner1: Vec3iLike, corner2: Vec3iLike, spanAxis: int = 0, riseAxis: int = 1, inverted: bool = False):
    ...

def archParabolic(...):
    ...

[Flashing-Blinkenlights]

Just a thought: It might make more sense to have a single arch function and to pass a style as a parameter (e.g. an Enum key), particularly since there are a lot of very different architectural arch styles (see https://en.wikipedia.org/wiki/Arch#Forms for some examples).

[avdstaaij]

Just a thought: It might make more sense to have a single arch function and to pass a style as a parameter (e.g. an Enum key), particularly since there are a lot of very different architectural arch styles (see https://en.wikipedia.org/wiki/Arch#Forms for some examples).

In my initial signature suggestion, there is a separate function for each arch style (round, parabolic, etc.). I considered using an enum instead, but I can think of two disadvantages of that approach:

1. Because the differences between the various styles are large, their implementations may have a lot of non-shared code. If we put all the implementations in a single function, the function might become very big. It might even become so big that we have to split it up into separate functions for each type... which defeats the purpose of using an enum.

2. Arches of different types may require different parameters (though I have not looked into this much yet). This can be handled much more elegantly with separated functions than with an enum.

[avdstaaij]

@cmoyates asked on Discord (paraphrased):
How do you want arches to behave when they are at different points on the third axis? (not span or rise)

Answer:
The points should simply repeat in the third axis (see https://en.wikipedia.org/wiki/Arch). Your remark does make me realize that there should probably be a 2D and a 3D variant for each arch, the former containing most of the arch code and the latter simply doing the repetition.

[avdstaaij]

There should probably also be a parameter that determines whether the arch is "filled", with the options (no fill, filled below, filled above). We may want to use an enum or a string parameter for this.

[avdstaaij]

Another bit of relevant discussion from the Discord:

@Flashing-Blinkenlights:
Ideally, arches would make use of stairs and slabs to better accommodate the curvature
In which case the parameters would be:

• position
• height
• width
• block(s)
• stair(s)
• slab(s)

@avdstaaij
Interesting idea! Not easy to implement, though...

@Flashing-Blinkenlights:
I don't think it should be too difficult if one pretends one is drawing the arc with quadruple the resolution, and then determining for each block (2x2 pixels) whether zero or one out of four (ignored), three out or four (stairs), or only the upper or lower pixels (slab) are 'filled', with anything else being a full block
Granted, it is an extra step, but I think hardly an insurmountable one

@avdstaaij
Actually, that's quite smart. That would allow us to write the algorithm only once and then we could easily select between full block or stairs/slab mode
Since it's just a different scale

(...)

@Flashing-Blinkenlights:
My thoughts precisely
Although in that case I'd just say slabs are empty and stairs are full blocks, then you don't need to change very much at all
And the user could decide whether to use only slabs, only stairs etc.