Transparency and Vectorial Hatches are some nice features of the 3D Documents, so the wish of combining these two for a single surface at some point (for example displaying mesh-like surfaces) is quite reasonable. Let’s see how to tweak the attributes to achieve this.
Just recently came across this issue that unit modules were meant to be linked into a block file, but due to the large amount of small variations within the units, the designers wanted to have a base module to link into the unit file as well, such as:
Module A is linked to the Units file onto different stories. In the Units file, small variations are added to the base A, which eventually results in Unit A1, A2, etc. Similarly with Unit type B, C and so on. Eventually the Unit file was linked story-by story into the Block file.
Though from attribute management point of view such amount of hotlinks is not easy to manage, the designers preferred this solution to deal with the frequent design changes of the 30+ unit types. At the end of the linking process the problem was, that since the Units file already contained more than 20 hotlinks, the total number of links significantly increased in the master file, which caused slowness in general, for scheduling, for updating the links and so on. If the Units file could have been a single file without previously added links it would have been much easier to handle. To overcome this issue, a tiny, but very powerful function of the Publisher was activated: Break nested Hotlinks and Xrefs.
Whenever publishing modules – in this case every story that contains one unit type was published as a separate module -, using the embedding function under Options… allows us to get rid of the excess links. At the same time the designers could still use the Units file for doing their work, but the process was not hindered later either.
As an additional benefit, the published modules only need to be linked once into the further files (typical stories or directly into the block), whenever there is an update, they just publish again with a click and update the links.
Setting up the Project Altitude properly and displaying its values for BIM Submission in Singapore requires a bit of insight of the Reference Levels function of ARCHICAD which the local practice might not be fully aware of.
ARCHICAD Meshes can be created in many different ways – by creating level ridges based on external drawings, by importing point clouds and modeling the terrain based on it or importing text files with the coordinates and then let ARCHICAD automatically build the terrain.
The first scenario is ideal as it will provide us with the contours that mark points at the same elevation, but other creation methods do not provide that natively. Using add-ons with more comprehensive earthwork-related functions can be an option, but for such a simple request we also have a solution within ARCHICAD.
I recently found a post on LinkedIn discussing the possibilities of labeling an abbreviation (ID or code) of elements, mainly the Surfaces. Since there is no perfect solution, two main ideas emerged other than using external label objects: use Labels along with Properties or IFC mapping. Though the first may seem to be easy to set up with ARCHICAD 20, it has its risks when it comes to change management since the Properties are not tied to other attributes that may change (for example Composite or Surface) unless you ALWAYS use Favorites, so let’s have a look at the Label tool options and the attributes instead.
The MEP Modeler gives good results when it comes to Collision Detection, but sometimes it is not that easy to identify the actual collisions despite the highlight options, especially if the project is larger. Let’s see an example and a quick enhancement of the representation.