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:
As we progress in this area, your input will be invaluable to understand priorities and our direction moving forward. Thanks in advance.
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?
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.
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.
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.
Firstly its great to be asked these questions. Thank you.
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 to be visualised differently compared to the whole element? Such as requirement for submission to highlight structural skins.
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?
See attached screenshot of a typical 1:10 scale ground floor detail that uses complex profiles and composites.
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.
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.
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
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
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
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.