Gh bake rework

[jonashaldemann]

Merged both Baking Components into one that bakes Beams & Plates. The Rhino Layers on which the elements should be baked can now also be defined.

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]

so is it ok that there's only one swap_uv? this will flip the coordinates for both beams and plates right? can it be user might want to flip for just one of them?

[jonashaldemann]

I've set swap_uv of the Beams to False, because we usually don't need it (yet):
self.add_brep_to_document(beam_breps, beam_frames, beam_layer_name, b_dimx, b_dimy, b_dimz, False)

But is there a clever way to avoid this unnecessary setting in this case without duplicating too many lines to solve Beams & Plates?

[chenkasirer]

@jonashaldemann looks generally good, although I did leave a few comments.

Now I'm not strictly against this re-work but keep in mind that as the selection of different element types grows, the number of input fields of this component is going to grow. This might end up being not very nice. But not sure having multiple components is the best solution either. Just something to keep in mind.

[jonashaldemann]

@jonashaldemann looks generally good, although I did leave a few comments.

Now I'm not strictly against this re-work but keep in mind that as the selection of different element types grows, the number of input fields of this component is going to grow. This might end up being not very nice. But not sure having multiple components is the best solution either. Just something to keep in mind.

Ok @chenkasirer, I see your objection. Maybe we can discuss it next week so I can estimate how many types there might be. Possibly the way is to create separate "Bakeries" but add the Layer Name Input to help assigning the Parts to Rhino Layers.