Ability to import/export Components between Wall/Slab/Roof Styles

[Tom W.]

Wall, Slab + Roof Components, in conjunction with the Classes they are assigned to + which control their appearance, are central to my building models. The specifics of the materials the building is constructed from – their name, thickness, unit size + thermal performance, their 2D + 3D appearance (via classes), plus in the case of things like timber framing, the spacing of the studs/rafters/joists – are all bound up in the components within my wall/slab/roof styles. In addition, material take-off calculations are derived by reporting on the same individual components as they are shared across different styles throughout the model.

 

With components being so central, it would be great, when creating new Wall/Slab/Roof styles, to be able to import existing components from other styles into the new style being edited. When you click on ‘New…’ you could have the option of browsing your files + identifying an existing style + selecting a component or components within it to bring into the new style. In a similar way to how layers + classes are imported into a file. There is inevitably a lot of repetition across Wall/Slab/Roof styles, as surfaces + materials are used multiple times in different contexts, and whilst you can create a new style by duplicating an existing one + in that way ‘import’ a number of components (+ therefore classes) into your new style, this only goes half the distance + it would be a really useful + powerful feature to be able to also identify components in other styles + bring them (+ their classes) into the new style as well. This would make things easier + quicker + help ensure consistency. I spend a lot of time clicking through styles, checking how I've set them up, to ensure that new styles are consistent. To examine a style in a closed file to determine the name of a component + what class it's assigned to means you have to open that file or import the resource into the current file.

 

I have not started using Materials yet so am not sure how they affect my argument but I assume it strengthens it, in that not only do you then have a class associated with a component but you also have a Material associated with it as well. So making Components transferable entities in themselves would be even more helpful?

[Jeff Prince]

@Tom W. That is an outstanding idea and should really be considered.  We should be able to build assemblies by simply picking, rather than configuring, the components.  This would emulate the actual method of construction.  A carpenter doesn't have to configure their materials before screwing them together 🙂

 

I suppose a manual method of controlling things would be to build slab kits for each use case (roof, slab, ceiling, hardscape, etc) built up with every possible component fully configured.  Then, when you need to generate a new slab style, simply delete the unneeded components and save it as a new style.  It's a bit silly, but would help achieve consistency when setting up a new office standard quickly.

[Tom Klaber]

Components as a resource!  Basically you could create a database, centralized project, or firm component libraries.  Could be very helpful.

[Boh]

This is a great idea. You have my vote!

[Matt Overton]

9 hours ago, Tom Klaber said:

Components as a resource!  Basically you could create a database, centralized project, or firm component libraries.  Could be very helpful.

Didn't we get a resource recently that made the same functional promise?

 

This wish seems to be well outside the mental model the developers are using of how buildings work. 

[Tom Klaber]

8 hours ago, Matt Overton said:

Didn't we get a resource recently that made the same functional promise?

 

This wish seems to be well outside the mental model the developers are using of how buildings work. 

Yeah - I was excited about Materials - too excited.  Jumped on that bandwagon - removed all of our material classes - spent a couple hours creating materials and assigning them to all of our walls...mistake - the limitations of materials meant I had to reinstate the class system - and then painfully remove the materials from the wall assemblies.  There could be a scenario where Materials have an optional thickness attribute so if used in walls - it would be a default component, since all other attributes - Rvalue, appearance + textures are in Materials.  2 birds?

[drelARCH]

On 6/20/2021 at 10:59 AM, Tom W. said:

plus in the case of things like timber framing, the spacing of the studs/rafters/joists – are all bound up in the components within my wall/slab/roof styles

Hi @Tom W.Could you explain more how you control in components spacing of studs/rafters/joists at present?... You mean using tiles as a fill? or am I missing something?

 

[Tom W.]

Hi @drelARCH I meant that I include in the component name details regarding the spacing of the framing, for example 'Wood Framing_70x45_600C-C (Insulated)', 'Wood Framing_95x45_400C-C (Insulated)', 'Batten_45x45_600C-C', 'Batten_50x11_150C-C', etc. This is more just to have that information recorded somewhere in the style rather than having any bearing on how the component is represented visually, and means I can return linear metre totals for the different sizes of framing timber by converting m2 to linear metres in a worksheet:

[MarcelP102]

Personally I don't need this. We already have so much style resources.. I think that a text auto complete function when typing the component name would do the same. Would that be a solution for your problem?

[Tom W.]

No I agree I don't think that Components need to become new resources, I would just like to be able to transfer settings from one style to another.

15 minutes ago, MarcelP102 said:

I think that a text auto complete function when typing the component name would do the same.

This would only transfer the name of the component to a new component + whilst this would help ensure components are consistently named it wouldn't deal with all the other elements that go into a component: thickness, thermal performance + 2D/3D appearance (via classes). You can import classes/sheet layers/design layers from any file in any location + bring them into your current file - and create standards files to store them in - and it would just be good to be able to do something similar with components: to copy + paste settings you've already created in one style to a new style. Or create a components standards file to use as a resource when creating new styles (a bit like what @jeff prince said)

[JMR]

A Component library / components as a resource would be a huge improvement. It has actually been wished for in 2019.

 

It's rather silly to have to do all the components again and again. There is no logical reason for it.

 

As a workaround, we have a "master" wall style which includes almost every imaginable wall component. To create a new wall style, we duplicated it and edit that. It's a rather clumsy method though but faster than starting from scratch.

 

 

 

 

 

[_James]

This would be very helpful. As we add more data to components to use systems like Energos or @Luka Stefanovic's new embodied carbon calculator it would save a huge amount of time to have something like this.

 

As people have pointed out, it mimics how things are actually built - by assembling products.

 

I don't know how it would be incorporated but perhaps there could be an option within materials to lock attributes such as thickness, thermal resistance etc. so in effect you could create a product such as a 100mm insulation board, 102.5mm brick or 18mm plywood etc.