Minimal space for statutory clearance around doors is a great feature, however there is a solid line displaying against wall when minimal space is turned on.
This is not generally an issue unless there are two doors next to each other, which then exposes the solid line. I have tested this on a number of basic standard library doors and it occurs in all instances. Graphisoft have indicated the same lineweight issue exists in ArchiCAD 27 & 28.
The issue is due to a limitation of the Minimal Space feature and it occurs because minimal spaces for doors are aligned with the length of the wall.
I wish the display of line weights and their location were more flexible within the Minimal Space feature.
On the attached I have highlighted the section solid line that I would like to remove.
Currently graphic overrides alter the appearance of only items before the marked distant area in cross sections, wrongly implying to the viewer that distant objects are not in the category that graphic overrides are trying to highlight.
Certainly, the case remains that distant objects should always look different/ more distant in section compared to close objects, but the graphic overrides dialog should also thus include an additional set of parameters to control distant objects appearance - or even better a 'smart.' pen intensity fading option based on main override pen colour, so no separate pen needs to be defined.
The current deficit in functionality is very problematic when the graphic override is intended to code items that meet a given criteria by pen colour - because the distant objects will continue to match the appearance of items outside that category, even when they belong within the category.
The below screenshot is from a section that has a graphic override applied such that all items in Design Option 2 are supposed to display in orange. But because the doors are in the marked distant area of the section marker, they wrongly display as unchanged (i.e. in grey) - wrongly communicating, for contractual and other purposes, that they are in Design Option 1
Currently, if a fill is set to display the fill area, the area text properties omits the standard text frame / opaque background offset parameter applying to other ArchiCAD text.
This prevents graphically important clear space displaying around the area text in the way that it does for all other text, and means that text characters with descenders (such as lower-case g) actually extends through the frame or across the edge of the opaque background.
2D fills using the Fill Category: Cover Fill do not count as actual Cover Fills...
Hi,
when managing windows and doors in big projects, the need for automatic dimensions of sub-elements (mullions etc) is critical. The solution today is to do annotate this manually, but when you change the criteria for the scheme, all these are lost.
We are losing a lot of hours just on redoing the dimensions manually, so an automatic solution for this would be highly appreciated.
Hi all,
Can we get the option to specify the depth of the Layout Subset Name autotext?
Project Name
T1 Subset Name
T2 Subset Name
Layout
T2 Subset Name
Layout
T1 Subset Name
T2 Subset Name
Layout
This is more relevant now with the introduction of Design Options where you may want a set of drawings for each option with a different title.
Alternatively, the a variation of the autotext Design Option Set Name could be made to act much like the Drawing Scale autotext where it will read all options on the layout.
Ling.
Trace Reference is one of Archicad’s most powerful and distinctive tools. It allows for highly precise multi‑level and multi‑concept design by overlaying drawings from other stories, views, or layouts. The graphic clarity it offers in plan is exceptional.
However, the Trace Reference is currently non‑printable, which often feels like a missed opportunity.
Many times, I simply want to print or export exactly what I’m already seeing on screen—including the trace reference—without recreating its appearance via graphic overrides, custom fills, duplicated views, or complex workarounds.
I propose adding a simple option such as:
This would convert the trace from a temporary visual aid to a printable overlay—optionally with its current graphic settings (color, opacity, line type, etc.).
Why this is useful:
Graphisoft Support Team:
For the life of me, I cannot figure out how to publish a layout with a "Split drawing among multi layouts" with sequential layout IDs?? This feature does not seem to work.
And, yes, we all understand that employing a subset is not required to accomplish this task, nor does it make it easier. I have already tried using subsets with zero success.
I wish I was a newbie to Ac, but I have been using Ac since version 4. Even my GS/AC reps, Chris Clark and Kevin Wichmann (whose names you may recognize), cannot figure out how to successfully use this feature. It has become another layer of frustration for all of us.
I have attached a screenshot showing a few of my settings for you.
In short, I am trying to create the following sequential id format: "A-606.00, A-606.01, A-606.02."
My base "A-606" layout is my wall assembly schedule layout or sheet with the spilt drawing, and all the subsequent drawings should have this A-606 prefix. I use the Classic NCS Format for my sheet IDs and I see no reason why this should be a factor in the final result? If it is, this should be fixed, everyone has their own method for labeling layouts/sheets.
I have also spent numerous hours manipulating all of my settings with no success. I have also spent numerous hours with Dimitrius (a GS support tech – US-based) trying to have him help out figure this out. Again, no luck.
Hence, my request for you guys to dive into this issue, check the coding, beta test it, and get this resolved. I know there are many workarounds on the internet. However, no one wants to use a workaround when the feature should automatically work flawlessly.
Automation is crucial to publish drawings successfully. And, while this is no small task, I believe it is an urgent matter for all ac users.
I look forward to your review and resolution, including escalating this issue to the top of the list, if you too feel the urgency to get this fixed.
I appreciate your time, attention and expertise!
E. Anderson
Earl Anderson Architects
I wish it was possible to show the following symbolic lines for drawers in elevation for Kitchen Cabinets (Base Cabinet Block):
It seems the function was added to show symbolic lines for drawers in plan only?
The ability to generate wall schedules that itemise wall types used within the project is a great tool for detailing wall types for construction.
However, the limitations of the schedule outweigh the benefit on using it (for example, there is no option in the scheme settings to list each composite layer and it's thickness). Instead, the recommended "work around" is to manually model each wall within the project and label it using using the Skin List Label.
I wish that the wall schedule could:
1. provide a 3D Plan View (rather than a "2D Plan View") that allows materials within the composite wall to be tagged with an active label, and
2. list the composite layers (like the Skin List Label does).
Example of wall schedule with desired labelled wall material shown in red:
Example of Skin List Label used for the same wall as a "work around" after manually modelling each wall in the project:
The "Composite" system is great but leads to an "Attribute Explosion." Creating a new composite for every single material variation is inefficient. We need a Finishing Tool (Skin) to apply coatings independently.
Key Requirements:
Wall, Slab, and Roof Finishes: A single tool to "skin" structural elements.
Independent Logic: Apply different tiles or paint to each face of a wall without changing the core structure.
Zone-Based Integration: Finishes should be linked to Zones, allowing them to update automatically if a room boundary moves.
Accurate Quantities: Net area calculations that automatically deduct openings (doors/windows) and small wall-mounted objects.
Why it matters: This would keep the attribute list clean and allow architects to change finishes in the late design stages without rebuilding the structural core of the model.
It is time to stop using generic "Slabs" and "Beams" to model structural foundations. Archicad needs a dedicated Foundation Toolset for better IFC classification and geometric accuracy.
Key Requirements:
Dedicated Entities: Specific tools for Isolated Footings, Strip Foundations, Piles, and Grade Beams.
Dynamic Interaction: Foundations should interact with the DTM (Terrain) to automatically generate excavation pits or recognize the soil level.
Technical Parameters: Native fields for reinforcement ratios, soil bearing capacity, and "lean concrete" (blinding) offsets.
Clean Geometry: Better intersections between piles and caps without complex SEO (Solid Element Operations).
Why it matters: This would streamline the structural coordination and ensure that IFC exports are correctly mapped from the start without manual renaming.
The current Mesh tool is no longer sufficient for modern BIM standards. We need a dedicated DTM (Digital Terrain Model) tool that behaves with engineering logic rather than just being a surface.
Key Requirements:
Existing vs. Proposed: Native management of terrain phases to automatically calculate Cut & Fill volumes.
Advanced Visualization: Independent display settings for 2D and 3D. We need to show contour lines and technical grids simultaneously without graphic override workarounds.
Infrastructure Tools: Integrated path and road tools that follow terrain slopes, including automatic curbs and longitudinal sections.
Logic: Similar to Allplan’s site tools, where the terrain is the starting point of the project, not just a decorative mesh.
Why it matters: Accuracy in site coordination and earthwork volumes is critical for the early stages of any project and for proper BIM collaboration.
Hi.
Relating to request #245503, we found that there´s a limitaiton in the values collected by AC in relation the corner window;
The Actual width = Window element + the extra corneringframe element
Can this please be added / calculated, in order to call the right dimensions in a schedule.
The dimension marked with red pens can´t be found anywhere in the system, or maybe I´m missing something here!
Cheers Thomas
Hello ,
Instead of the buggy " zone linked elements " function inside ArchiCAD, which automatically detects elements placed inside or at the zone boundaries, it would be very nice to have manual link possibilities ,
a big slab that covers multiple zones could be linked to them all,
i can choose to which zone i want to link a wall , or a dorr, manually ,
When dimensioning sections for formwork drawings, dimensions for wallholes do not associate and any change in doors / windows will not update dimensions, which leads to errors if sections are not monitored constantly. For a small three apartment building I have more than 20 sections per floor and it's really hard to keep up with all the dimensions that are not updating automatically.
This is a section that goes through a garage door. The 12,5 cm dimension and -0,625 elevation dimension will not update if I change height of the door. Wallholes should have automatic hotspots - when you place dimensions, it should be a circle on the hotspot, not a square.
Sunshades should be hidden in some views, this should be achived by mvo like other window components, for consistency and efficiency
Currently properties are identified by archicad by a GUID, which is what is referenced by labels and schedules. However, in different files identical properties have different GUID, unless they are all created from the same mother-file. When using hotlinks with exported .mod-files (and break links checked) the properties in the .mod-files always gets different GUID. This makes it impossible to place labels pointing to a property in a module file, because when placing that module in another file the GUID has changed and the label no longer has anything to point to, resulting in "---".
The GUID is not visible (except when it is missing or by using custom GDL objects especially for this purpose) and it is not editable. It would be better if properties were identified by name, or by an index number like other attributes, with an index changer function included.