Component Level Design Workflows - Conversation & feedback

[James B]

Hi All,

Now in Archicad, most design and data are handled at the element level - assigning properties, using Graphic Overrides or setting renovation status are a few examples.

To express design intent and extract data at a more detailed level, the component or skin level requires further data and flexibility. We already visualise these skins, have Offset Modifiers for Profiles to create smart parametric extrusions, and Component/Surface Schedules to extract data.

We plan to further develop the component/skin level of elements and expand existing functionality in that area, so we are exploring more about what you need. Some questions:

• What type of data do you need to store in components/skins that may be separate or different to existing Building Material properties?
• How is this data used and presented in documentation and schedules?
• Renovation of components, are similar for the same composite/profile? Or mostly unique for all placed elements separately?
• Modelling flexibility of components, in which common situations are you resorting to workarounds, like stacking elements, that existing composites/profiles with modifiers can't achieve?
• Visualisation of components, in which situations do components need be visualised differently compared to the whole element? Such as requirement for submission to highlight structural skins.

As we progress in this area, your input will be invaluable to understand priorities and our direction moving forward. Thanks in advance.

[Ahmed_K]

Hi insiders

Can we have an update on this development? 

Thanks

[Ahmed_K]

I'm deeply exploring the process of 4d and 5d modelling, and the site quantity survey to track accomplished work.

Component level design will fix alot of workarounds and impossible tasks , like skins by zone, skins by facade, floor finishes by zone, quantity of wall finish by zone faces, and more.

Now, the only way is to model each skin as a separate wall/slab,

[Karl Ottenstein]

Exactly.  And Graphisoft realized this more than 20 years ago when they had the "Constructor" line of 4d/5d software (later sold) which had to re-model those elements.  It would be nice to see fine-grained component/skin/etc control in Archicad itself.

https://mail.aecbytes.com/newsletter/2004/issue_15.html

[Ahmed_K]

here is a common exemple for me : 

wall skins relation to zone is crucial, 

when we make takeoffs, and to ensure all is correct, we need to se the relation of an element / component to the related zone, 

this will be our starting point for quantity statements onsite, and for tracking site work evolution

Composite Wall 01 start from room 1 to room 2, 

it's skins belong sometimes to room 1, sometimes to room 2, and some times to the façade

A small beam under the wall is used to cover the slab edge, it has the same material as the exterior wall finish.

To quantify materials there is a logic : 

• If it's interior : locate the material by it's zone
• If it's exterior, locate the material on the façade.

you can divide the wall , and say, hey this segment is for room 1 and this is for room 2, ok it will work, nut not for too long :

• The interior finish quantity comes from the component schedule, it can show the related zone in component schedule (room 1 for ex.)
• The exterior finish should be located by façade number, and since we use the same BM for different elements, located on multiple façades, you can't assign that to properties in the BM itself, this information comes from the element level, a property to devine the façade Number, of the element, and here starts inconsistency : 
  you need an element schedule to call all elements by their unique ID : UNIQUE ID ------ Façade N°
  And a component level to match the components ( exterior finish coming from wall 1 exterior , wall 2 exterior , beam, etc ) with the original element 
  
  Element schedule :       UNIQUE ID ------ Façade N°
  Component schedule : UNIQUE ID ( element level )  ------ Material name
  
  Final result Façade N° ---------- Material name 
  

At the end you may come with missy data, and a lot of table you can''t manage

If the skins could receive properties, that could solve a lot of workarounds , 

The data structure could be like that : 

• Material properties : specifications, thermal Data, material composition etc 
• Skin property :
  • own properties : like relation to zones, Interior facade number....
  • inherited properties : inherited from the parent level : element ID, element storey level, 
    The alteration between those levels can be done in the property pet palette
• Element property : the same we're using now.

[Ahmed_K]

Does someone faced theese situations before ? Is this workflow common for you guys ?

[mthd]

Skin by Skin design was listed on the original roadmap. Is this what is meant by component level design workflows ? 

[Rodger Walsh]

Expanding component-level workflows is a great step. More flexibility in assigning unique data, renovation tracking, editing things, and visualization for individual skins would enhance design clarity, reduce workarounds, and improve documentation and material takeoffs.