Lap BTLx Feature // T-Butt & L-Butt

[papachap]

This PR introduces a new BTLxLap processing feature and Updates the T-Butt and L-Butt joints so that they follow the new system of joint definition (ie the use of the alt constructors of the JackRafterCut and Lap classes).

This means that the ButtJoint module can eventually be removed.

Also this PR fixes a bug in the calculations of angle and inclination of the JackRafterCut.

What type of change is this?

• Bug fix in a backwards-compatible manner.
• New feature in a backwards-compatible manner.
• Breaking change: bug fix or new feature that involve incompatible API changes.
• Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• I ran all tests on my computer and it's all green (i.e. invoke test).
• I ran lint on my computer and there are no errors (i.e. invoke lint).
• I added new functions/classes and made them available on a second-level import, e.g. compas_timber.datastructures.Beam.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate)

[papachap]

I haven't removed the ButtJoint module, although it has been completely removed from the T-Butt and L-Butt joints. Let me know if you would like to do this in this PR or in a separate one.

[papachap]

Adjustments based on the comments from @chenkasirer done 👍

[obucklin]

I worry that we are implementing overly-simplified geometric implementations of the BTLx Processings. I would prefer that we make these more complete so that we don't have to go back later. This is particularly true for the Lap Processing, which will lose functionality with this. I know this is currently only for the Butt Joints, but it's worth considering if we should just implement fully immediately.

[obucklin]

I think this is a simplification of what we had previously. For example it doesn't take into account the inclination, lead_angle, etc. The old definition did account for these things, and this should use those too. The subtraction can't really be represented by a Box. As far as I can tell, this will only work for beams that are orthogonal to one another.

[chenkasirer]

discussed with @papachap, I agree we should at least be able to do what was possible before AKA arbitrary laps as a result of lap joinery.

a potential solution would be a from_beam_beam() constructor that follows similar logic as the current lap joint. see implementation by @jonashaldemann:

compas_timber/src/compas_timber/connections/lap_joint.py

Line 128 in 295c3ff

def _create_negative_volumes(self):

[papachap]

This is true that it is a simplification. For sure It is wise to implement an additional alternative constructor as @chenkasirer suggested in order to allow for non box-like laps by using the two beams to extract the params.

Also the geometrical representation can be done with a polyhedron volume rather than a box.

In regards to the joint definitions of TButtJoint & LButtJoint though, this simplification existed from before as the inclination was set to 90 degrees by default. See:

compas_timber/src/compas_timber/connections/t_butt.py

Line 86 in 295c3ff

self.cross_beam.add_features(MillVolume(self.subtraction_volume()))

But it doesn't require the beams to be orthogonal, it will just create a lap as the one you can see in the picture below.

The _create_negative_volumes() was used for the Lap joints but was not handling the generation of the machining parameters of the lap processings.

Let me know if we want to keep this simplification to any of those joint definitions.

[papachap]

I worry that we are implementing overly-simplified geometric implementations of the BTLx Processings. I would prefer that we make these more complete so that we don't have to go back later. This is particularly true for the Lap Processing, which will lose functionality with this. I know this is currently only for the Butt Joints, but it's worth considering if we should just implement fully immediately.

I agree with your point, and I think in this case it can be resolved by implementing an additional alternative constructor. But in my opinion in some of the joint definitions this simplification could be valuable. Let me know what you guys think @chenkasirer @obucklin

[papachap]

@obucklin After discussing with @chenkasirer, we agreed it would be wise to split the Lap Processing development into two PRs. The main reason is that this PR’s primary goal is to update the old implementations, at least when it comes to machining processes. Since lap joints currently only allow for geometric representation without the ability to extract machining parameters, we can accept that the alternative constructor introduced here is mainly intended for butt joints.

In a follow up PR, we can develop a new constructor that allows for the generation of a more advanced Lap processing, that would handle lap joints and would be able to extract the necessary machining parameters. (And also have the lap be represented as a volume rather than as a box).

[chenkasirer]

LGTM
there's a follow-up task #332 to complete the Lap visualization together with the Half-laps