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.

[Nathan Hildebrandt]

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

[James B]

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.

[Nathan Hildebrandt]

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.

[James B]

Thanks Nathan for the additional feedback. Much appreciated.

[DGSketcher]

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.

[James B]

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.

[DGSketcher]

@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.

[Tim Ball]

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!

[James B]

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?

[Tim Ball]

Hi James

See attached screenshot of a typical 1:10 scale ground floor detail that uses complex profiles and composites.

• The wall detail between the footing and the timber frame wall is a complex profile that interacts with the edge of the slab which is a composite
• The timber frame complex profile includes
  blockwork above floor level
  insulation between the frames
  Internal service void and vapour barrier
  Internal plasterboard and plaster finish
  So it's all quite a complex area to manage
• All the elements have property data attached that is used to generate the auto-text drawing notes. The same property data is included in the specification that also includes more text that does not need to show on the drawing

So as you can see there is huge potential for enhancing the creation of the complex profile geometry and also the data handling. These improvements would help with live detailing immensely. I don't use the detail tool at all, but I also don't draw any 2D for my details.

[James B]

Thanks Tim, so your primary workflow is wanting to annotate details of 3D elements (in your case complex profiles) without having to use the Detail Tool. So any data that we can add to 3D components, and be able to label, would be beneficial in your example.

[Tim Ball]

Hi James

The key is that each element has its own specification data attached and so that feeds into the annotation using autotext, bit also lists as a specification using the schedule tool

[James B]

Hi Tim, for you having name, id and description would be the types of information you'd like to output as autotext? (like your attached example previously).

[Tim Ball]

You can access any data you need pretty much from any element using autotext. You just decide whatever data suits your own workflow and add the properties needed. The  extra bit is to access the renovation and building materials data that is within a complex profile

[abdelaziz]

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

[James B]

Hi Aziz,

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

[abdelaziz]

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

[abdelaziz]

Hi James

attached is a representation of what I imagine for the composite manager

[PB]

Abdelaziz, this is exactly what we are hoping/waiting for with composites & complex profiles - great interface idea. We are currently having to create an existing/demolition file and then work on a duplicate file for proposed works on all renovation projects...frustrating...

[James B]

Hi Aziz.

Ok so you're using Surface Overrides in most situations if I understand correctly. When would these surfaces change in what views or in which situation? You mentioned graphic overrides earlier.

It seems you need some additional data on this surface override to be able to output. Can you outline what data you need for these outer skins?

Also, thanks for your enthusiasm with your interfaces. We're a long way from suggesting any solutions yet, but trying to gather the use cases and problems around this topic first.