implemented direct BTLx application

[obucklin]

This PR is working toward removing the FeatureDefinition class. The BTLxFeatureDefinition GH component previously generated a FeatureDefinition, but the BTLxProcessing should (arguably) just be applied to the element directly, as it doesn't have any relationship to the Model or joinery processes. This makes minor changes to Element and 'BTLx` and changes a few GH components.

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)

[chenkasirer]

is_joinery_feature is a good addition, as it is a useful distinction when serializing beams.

With the rest I am a bit conflicted. this somewhat contradicts the idea of deferred processing which I think is what is needed here. main reason is that the beam component is too early to set processings as these stay fixed while the beam may get extended due to joinery downstream.

[obucklin]

is_joinery_feature is a good addition, as it is a useful distinction when serializing beams.

With the rest I am a bit conflicted. this somewhat contradicts the idea of deferred processing which I think is what is needed here. main reason is that the beam component is too early to set processings as these stay fixed while the beam may get extended due to joinery downstream.

I understand, but I also think adding a BTLx Processing directly to an element is fundamental and should be supported. In this case one would declare the parameters directly, and those parameters do not change, regardless of when they are declared. It is true that the resulting geometry would not be the same if extensions are added, but the parameters themselves are not changed.

I want to be able to see the effect changing the BTLx parameters has on the geometry without needing to go through joints and models. I think a beam should be able to have features without needing to be part of a model.

[obucklin]

I understand, but I also think adding a BTLx Processing directly to an element is fundamental and should be supported.

plus, we do this in code anyway

[obucklin]

this somewhat contradicts the idea of deferred processing

just one more thing, this is related to the deferred processing because it is explicitly not deferred. We only need to defer if we are passing geometry or other params on that would get changed down the road before processing. This declares the params directly and assumes they are not changed again. If we made this a deferred processing, I would still not change the params based on extensions, etc.

[chenkasirer]

as you mentioned, adding processings directly to a beam is already supported. in fact, that's the only way it works.

my concern is specifically for this GH flow, where processings applied to beams need to be applied in the appropriate sequence to ensure a correct result. I do think users should be able to add non-joinery processings (via deferred processings) but the actual application should be managed by the model component to prevent unexpected results.

perhaps another component, something like a BTLxPreview (takes Beams and Processings, makes a copy of the beam, applies processings and visualizes the result), could be a good compromise for sandbox needs?

[obucklin]

as you mentioned, adding processings directly to a beam is already supported. in fact, that's the only way it works.

my concern is specifically for this GH flow, where processings applied to beams need to be applied in the appropriate sequence to ensure a correct result. I do think users should be able to add non-joinery processings (via deferred processings) but the actual application should be managed by the model component to prevent unexpected results.

perhaps another component, something like a BTLxPreview (takes Beams and Processings, makes a copy of the beam, applies processings and visualizes the result), could be a good compromise for sandbox needs?

I understand the concern. However, as I stated earlier, because this workflow allows users to set BTLx Parameters directly, the order of operations doesn't make any difference, because those parameters will not change. I think order only matters for Joints. AFAIK the features don't interact with each other in any way, so order of their application shouldn't matter. They are all applied at the end anyways when the geometry is created.

I reckon we had better discuss in person to work it out. :-D