topic Re: Component Level Design Workflows - Conversation & feedback in General discussions

Component Level Design Workflows - Conversation & feedback

James B — Wed, 24 May 2023 08:38:06 GMT

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.

Re: Component Level Design Workflows - Conversation & feedback

Nathan Hildebrandt — Wed, 26 Oct 2022 14:23:39 GMT

What type of data do you need to store in components/skins that may be separate or different to existing Building Material properties? If there is the ability to extract all of the information at a component level from a Building Material and its properties it would be a great start. But at the same time there then needs to be the ability to have information at a composite / complex profile with its properties at the type level. Then there could be a need for renovation status and surface overrides for each component / skin.
How is this data used and presented in documentation and schedules? Not used at this point in time as there are too many work arounds needed to make it work properly. If it is implemented properly I can see schedules, IFC exports and BIMx exports using this information.
Renovation of components, are similar for the same composite/profile? Or mostly unique for all placed elements separately? Renovation at the skin level would be great (noting there may also be a need for surface overrides to be set to different finishes based on renovation status, imagine a wall that is repainted, but the wall is kept existing we just need to tell people it is painted.
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? The inability to label the skin that is clicked on is a huge restriction in my use of Complex Profiles (made up of multiple skins). Therefore I build composites and stack as needed. Then with a custom label I can label the outside or inside skin of the wall.
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. A diagrammatic section or 3D document would be an area where this could be of benefit.

Re: Component Level Design Workflows - Conversation & feedback

DGSketcher — Wed, 26 Oct 2022 20:19:56 GMT

Hi James, I think some of the Q's are a bit vague, probably deliberate, so I will throw out my initial thoughts to get the ball rolling...

The biggest frustration in the management of element data is the breakdown between Details & "Live" Sections. Details are an issue in themselves, but the destruction of data that occurs when all the info is converted to 2D isn't great. Live sections have the advantage of retaining much of the element data - Size, Classification, Categories etc, but it isn't currently possible to associate a label with a sub-element e.g. I may want to do a skin list in one view, but in a more detailed view I might want to reference the data of individual skins for a more descriptive label.

I have probably dropped the ball in recent years regarding embedded data as there doesn't seem to have been a coherent strategy on assignment and access. The current data sources classification, properties, categories, IFC assignments and other input feels scattered and difficult to manage. Overall though assigning values to complex elements and individual materials share many similarities e.g. both need categories, manufacturer, description etc, but the binding that data in complex elements requires a way to access the sub elements.

There is also some frustration with data that can be entered, but not accessed. Case in point is the Description field for Classifications. It has been mentioned before that the ability to optionally label an element with the Description would provide a second level of info that could be relied upon as it is tied to the Classification e.g. In some drawings I may just want the Classification code/ name, but in a more detailed drawing I would like to use the description which more fully describes the element and works associated.

It would also be nice feature in those classification & description fields if there were place holders to assign derived geometry, property or custom values e.g. Concrete slab #Thicknessmm deep. Finish: #PropFinish. Refer to Str. Eng drawing #Custom.

Assigning GO's to building materials to impact sub-elements has been requested regularly over the years, particularly in respect of glass in windows, but it would also be useful in highlighting the structure e.g. a core steel beam embedded in a complex profile or differentiating between wet coatings and dry board finishes assigned to a composite wall. I am sure there are many other possibilities.

Re: Component Level Design Workflows - Conversation & feedback

Tim Ball — Wed, 26 Oct 2022 19:13:03 GMT

Firstly its great to be asked these questions. Thank you.

My thoughts

What type of data do you need to store in components/skins that may be separate or different to existing Building Material properties?

Components and skins should only use building materials to avoid confusion
I like the way any property can be attached to a building material because that gives everyone the option to embed the data most relevant to their way of working and building type. That option should be retained

How is this data used and presented in documentation and schedules?

I use the data extracted from elements at the moment because it's not possible to extract the data from complex profiles
Extracting data from complex profile “types” is important because even though the materials may be the same, the thicknesses and build up may differ
Interfaces between different elements are very difficult at the moment. Complex profiles can help with that but for instance you may want to add a DPC or flashing to a complex profile and if you do it's impossible to get data from those secondary elements
Indeed the way AC handles junctions generally is not good enough, just see the window sill and head details as an example. If we could actually get a window tool that has complex profiles embedded in it to handle the reveals, sill and head that would be great. If we could then access that data it would be even better
Many elements require several different trades on site to actually build them. For instance a wall with a plaster finish. Therefore you need to read the data into different schedules for use by different trades or suppliers
Complex profiles often change as the project progresses. For instance a simple profile at design stage can be edited to show more detail at working drawing stage

Renovation of components, are similar for the same composite/profile? Or mostly unique for all placed elements separately?

Complex profiles should work with the renovation filter and so each building material needs to have renovation data attached. That applies to demolished items too

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?

Window and door lintels are an example where you have to add them as beams, complete with the combination of internal finishes and reveals
Same applies to roof and slab edges

Visualisation of components, in which situations do components need to be visualised differently compared to the whole element? Such as requirement for submission to highlight structural skins.

Cutaway sections are possible using 3D documents but the cut geometry is limited. It would be nice to control that more creatively so that you could illustrate a wall type by say peeling back different skins
It would be really useful to have access to the complex profile editor in a way that allows you to show that as a "type" that doesn't read as part of the building but is linked to the elements that use that type. That could form the basis for the graphical illustration in a schedule
It would also be useful to be able to show a cross section graphically in a schedule, in 3D, plan and section to make schedules more relatable. Schedules need to be easy to read or no one will use them!

Re: Component Level Design Workflows - Conversation & feedback

abdelaziz — Thu, 27 Oct 2022 05:30:23 GMT

Hi James

sometimes in the finishing location plans we use the same layer for the coating but we want for example to identify the paint finish via a specific RAL, it would be good if the finishing surface had a direct relationship with the finishing layer, for example if the inside surface of a wall is RAL 9001 so graphic override impacts the finish coat in the composite

_What I mean with this example is that sometimes the renovation project does not require changing the composite skin, just modifying the skin by the surface to be used, for a correct plan representation, to simplify things imagine working on a renovation project where you have to renovate the paint and wallpaper without modifying the finishing skin

Re: Component Level Design Workflows - Conversation & feedback

Gerry Leonor — Thu, 27 Oct 2022 03:49:25 GMT

Would much prefer to avoid intentional / workaround duplicated attributes.

duplicate Building Materials to achieve a desired look / construction sequence for intersecting walls. It'd be great if we can have a sub-setting within the Composite Settings to allow us to manipulate intersection properties on top of the Building Material priorities.
duplicate custom profiles to differentiate between a column (profile center) and a segmented beam (center top flange). Segmented Beams need to allow for an offset dimension to properly position a profile relative to their differing centers.

a better Detail Tool. the fact that the current Detail Tool takes a 2D snapshot which explodes 3D elements into simpler 2D attributes is not just wrong, but dangerous. you lose all your BIM information & you're having to re-label things that suit a more 2D drawing & move away from the 3D practice. if/when we do retain the 3D elements in an updated Detail Tool, the ability to label individual composite skins should be available & grab whatever pre-set notes are in there.

other things:

I don't mind modelling a separate wall for a tile finish VS the substrate/structure -- this allows me to have a different Surface direction / origin point than the rest of the wall. if the Surface origin/direction can be different for each face of an element (beam/wall/slab/roof etc), this would simplify things.

Re: Component Level Design Workflows - Conversation & feedback

Dendarii — Thu, 27 Oct 2022 05:44:06 GMT

Great topic; I think complex profiles are one of the most powerful tools, which are difficult to use in real life documentation situations due to current limitations.

- For each Component within the Complex Profile add the ability to assign element ID, properties/classifications etc. as each Component is a unique 3D building element (ie. gutter/fascia/soffit/flashing within a single Complex Profile. Currently all Components are grouped as a single element and we lose all the information required for documentation.

- Allow Trace function to be enabled within the Complex Profile window, as we currently model profiles blind.

- Yes renovation filter enabled for each Component would be nice.

- Yes Graphic Override ability for each Component would be great.

- I've had issues with offset modifiers and curved surfaces, not sure if I just don't know how to make it work!

- I would love to see the Complex Profile tool expanded into 3 Dimensions ie. model in 3d and click surfaces/edges to apply offset modifiers etc. to create a visual parametric library part maker tool (would be similar to Revit families).

Thanks!

Re: Component Level Design Workflows - Conversation & feedback

maro — Thu, 27 Oct 2022 08:22:00 GMT

Hi James,
Yes renovation filter enabled for each Component would be great .
Then under Composites - New Skin start from Existing Skin (there is overlaping Demolished and New Skins)
Thanks
Marek

Re: Component Level Design Workflows - Conversation & feedback

Miha_M — Thu, 27 Oct 2022 10:23:21 GMT

What type of data do you need to store in components/skins that may be separate or different to existing Building Material properties? Composite elements are a nice shortcut, but not applicable in refurbishing or reconstruction projects. We need each composite skin control (renovation status, graphic overrides) and properties/classification enabled. Here I would also suggest a radical change for windows and doors functionality. A window/door element should become a combination of a library element and a opening element, where the opening element's functionality could be expanded into so many things we would like to use...
How is this data used and presented in documentation and schedules? Here I would suggest a serious schedules upgrade - addressable cells and the ability to use expressions. Combined with the ability to list separate composite skins and windows/doors with or without their corresponding openings this would open up a whole new world of data control and output. We also urgently need better control of graphic presentation of elements in schedules.
Renovation of components, are similar for the same composite/profile? Or mostly unique for all placed elements separately? Unique for all placed elements.
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? With workarounds almost anything can be done, but it's sad that this needs to be done with "workarounds". I mostly have to stack two or more elements to get what I need. I think the current composites and profiles should get reengineered into a new workflow with stacked elements by default.
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. I did not have any need to visualize such components in the past, but this option would be a great addition and could be used on many occasions (presentation to clients, during construcion works, FM, etc.)

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 11:07:05 GMT

Hi Nathan, thanks for the feedback.

If you could label a skin/component, and be able to output existing Building Material Properties, how would that change your workflow? What information would you show in these label or would want to? In which kind of documents? And what existing limitations do you see with extracting that data in Schedules that you mentioned?

For visualisation of components separately, could you provide an example of the type of diagrammatic section or 3D document you're thinking about?

Thanks.

Re: Component Level Design Workflows - Conversation & feedback

Nathan Hildebrandt — Thu, 27 Oct 2022 12:00:12 GMT

Hi James,

An example of a workflow I use currently is a wall type schedule. In plan I will use a custom label to tag each wall with the start of the Composite Name (before the first space). And then I create also in plan a series of short wall segments to represent each wall type that I have in my project. Each composite is labelled with a custom label once again which breaks up the skins and their thickness together with the full composite name and arrows pointing to each skin. The label that we had at Fulton Trotter was 10 times more over the top than this one as it included fire ratings and smoke ratings and R Ratings for external walls.

This is only one workflow I use now and have held off doing anything more because of limitations with having mixed tools doing similar tasks. I somewhat feel like the ability to script custom labels is what is holding me back from pushing this any further. I also am not a fan of Archicad Properties yet because they are handled at the instance level, if they were handled at the Composite and Complex Profile level then I would look to use that information in my workflows. The problem with instance based properties for composites and complex profiles is that if you change it the properties do not automatically change with it, so there is a potential for information conflict.

With all of the discussion about key notes, I think they are old and not really needed, if Archicad properties are addressed properly across all attributes then that information could be used to tag, note, describe every element that is placed in the model across plans, sections, internal elevations and even details.

The challenges with schedules, is a big one because you are not able to get all of the information in a single schedule for all element types, which forces you to either model things using a single method, or you end up having to create multiple schedules and then sit them below one another. I honestly have put as little information into Archicad as I can and use Attributes as my single point of truth and have the rest of the information in my specification, because of these problems within the software.

The main area without thinking of every possibility right this second would be where you change the scale of a drawing. At 1:100 you want to see a wall a particular way, at 1:50, 1:20, and 1:5 you would want to progressively see more detail or clarity or separation. At the moment I trick this with pen sets and graphic overrides.

Hope this helps a bit more.

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 13:41:41 GMT

Thanks Nathan for the additional feedback. Much appreciated.

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 13:54:06 GMT

Thanks for the feedback.

What type of data in a label for an individual skin would you want to show? Any examples would be helpful.

We're aware of the request to have GO for skins (outlined on this forum and recently in the other discussion from my colleague). Would be happy to hear more use cases of the types of overrides or outputs you want to achieve and for what purpose.

Re: Component Level Design Workflows - Conversation & feedback

kmitotk — Sat, 29 Oct 2022 13:31:28 GMT

What type of data do you need to store in components/skins that may be separate or different to existing Building Material properties?

We currently don't have a proper place to put the properties/specifications of the finish materials with negligible thickness such as paint/coating/wallpaper. We normally use Surfaces for these materials but as we all know custom properties are not available with Surfaces. We wish we can somehow include these materials in Building Materials and use them in composites/profiles. Currently if you tried to do that you'd end up having infinite variations of basically the same composites/profiles which is not practical. Maybe we should make the outermost skin overwritable to another BM at the instance level? Please address this problem and come up with a good solution. I believe all the material information should be located in Building Materials so we can centrally manage them in one place. We should be able to list all the materials and their specs in a single schedule.

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 15:58:27 GMT

Hi Tim, thanks also for the input.

Clarifying your comment on the data from Complex Profile skins. Can you elaborate further on what (you mentioned thickness) type of data, and where or how you'd use this data?

Regarding renovation in profiles, do you need to change renovation of skins for the same profile everywhere?

Re: Component Level Design Workflows - Conversation & feedback

abdelaziz — Thu, 27 Oct 2022 15:59:41 GMT

as I said in my previous message, this problem can be solved by the GO, a rule that allows to replace the skin finish according to the surface applied on the interior or exterior part of the wall for example

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 16:02:34 GMT

Hi Aziz,

Is the coating/paint you're referring to, using Surface Overrides? Or defined by the Building Material in the skin? Thanks.

Re: Component Level Design Workflows - Conversation & feedback

James B — Thu, 27 Oct 2022 16:14:14 GMT

Hi Gerry, thanks for your input.

If you could label a skin directly, with Building Material Properties, do you see yourself using Details less?

Can you provide some examples of 2 or more surfaces needing different directions that are on the same element? Is this primarily when using Surface Overrides on those element types?

Thanks.

Re: Component Level Design Workflows - Conversation & feedback

abdelaziz — Thu, 27 Oct 2022 16:45:11 GMT

Hello James

Is the coating/paint you're referring to, using Surface Overrides?

the surface covering on the interior or exterior face of the wall is not applied by a graphic replacement rule because it must be easily modifiable for any user

Or defined by the Building Material in the skin?

it is not defined by the building material, the building material remains the same, it is the interior/exterior surface that changes

_we want to create a graphical replacement rule that detects the surface of the wall to graphically replace the topcoat linked to that surface. Thanks James

Re: Component Level Design Workflows - Conversation & feedback

DGSketcher — Thu, 27 Oct 2022 16:51:18 GMT

@James B Examples sent by DM. GO's not really a problem for me apart from the upside down list processing and mismatch with the criteria of interactive schedules.