The Making of Point Clouds in ARCHICAD 19

This post is by Ferenc Traser, a Product Designer at GRAPHISOFT. Ferenc has an MArch from Budapest University of Technology and Economics and an MS Arch from DAAP at the University of Cincinnati. Prior to joining GRAPHISOFT, he practiced as an architect, mainly working on historic preservation projects. Having surveyed historic buildings by hand, making point clouds usable directly in ARCHICAD was particularly important to him.

While planning the new features of ARCHICAD 19, we quickly realized that a rapidly developing area in architecture has been missing from previous versions. Known for decades as geographical information system (GIS), this technology has recently made a significant impact on architectural representation and surveying. Remote sensing is now used to analyze not only terrains but also smaller scale objects: streets, buildings, interiors, and engineering details. Architecture firms worldwide believe that instead of spending money on the slow and expensive method of hand surveying, it is cheaper, more reliable and definitely faster to create point cloud models. Now that the hardware has become more affordable for smaller firms as well, it was time for ARCHICAD to gain a foothold in this area.

The idea of point clouds is simple: it is an array of points in 3D, each of which is assigned X, Y, Z coordinates and RGB color values. It became apparent to us that a third type of value, intensity, is also used to represent the grayscale spectrum. In some cases, color is simply discarded: the 3D information and intensity values are enough to distinguish between points for modeling. This rather simple set of data is carried by various file types; almost every hardware provider has its own. We chose two that are independent and started to implement them in ARCHICAD.

The point cloud feature in ARCHICAD is a first in many ways. Points as a type of geometry did not exist before; everything was made out of either 2D or 3D sub-elements. Point clouds are enormous in size compared to other objects; millions of points can take up gigabytes of disk space and memory. They are also one of the few multistory GDL elements whose size on the floor plan may vary from story to story. Once you import them, point clouds come in twos, because ARCHICAD generates two files.

One of the formats we ended up using is cleverly named XYZ. Basically it is a text file containing any number of columns (generally six or seven). Since there is no standard, the challenge I faced was to create a method for deciding which columns to use for what values, namely XYZ or RGB. Unfortunately this simple mapping lacks the use of the third set of data, intensity. The other file format, E57, doesn’t need this mapping procedure.

During the design and development process, we received a test point cloud file from Japan that showed everything in black. As it turned out, all the RGB values were set between 0 and 1. I managed to open the file in Excel and multiplied those numbers by 255. The problem was that in Excel there are only about 1 million rows, therefore opening and tweaking anything larger than that has its limitations. Our small test file had at least twice as much, so when I finally managed to open the point cloud in ARCHICAD, I could see a room almost cut in half diagonally. Only half of the points made it through my conversion efforts.

Another fine example for how different these files can be is that they are not necessarily uniformly scaled. We have encountered a few examples where the Z value of the points was 100 times less than X and Y. This is why we implemented a non-uniform scaling option in the GDL settings.

Before point clouds, only a handful of GDL elements spanned multiple ARCHICAD stories; except for pipes and trusses, they are all located on a single story. This became significant when we realized that the anchor points of GDL elements are derived from their story-based bounding boxes. Since a point cloud can be in any shape and size, this bounding box constantly changes from story to story. This means, for example, that if you elevate a point cloud, you reshape its apparent size on the floor plan, thus moving its anchor point and its horizontal position as well. After a long debate we decided that a point cloud should only have one anchor point.

When writing the requirements for this project and eventually what ARCHICAD should do with point clouds, we realized that snapping onto points may be out of scope. I am no developer, but I could understand the need for this limitation in the case of millions of points in one single view. I imagined that tracing points with snapping would be the ideal workflow and would improve usability immensely. At the very last moment, it turned out that activating snapping on point clouds is quite simple, and there have been many developments that improved performance in that area as well.

What does the future hold? We will have to support intensity in addition to color. Make performance better and be able to import even larger files. In my opinion, we must enable point clouds for any output: it would be an ideal tool for creating architectural context. Recognizing BIM elements from point clouds may be too far in the future, although companies like ClearEdge3D aim to do just that. But maybe tracing simple surface geometries like planes or tubes can be a good way to start. Whatever direction we take, it all depends on you: how would you like use point clouds in ARCHICAD in the future?

Point cloud images: Bradford College, UK, Bond Bryan Architects,

Did you enjoy this post from someone who helped shape ARCHICAD? Let Ferenc know in the comments. I thought it was super interesting. And I hope it won’t be the last time we have someone from GRAPHISOFT sharing their thoughts about the evolution of ARCHICAD on the blog. Subscribe to the blog so that you don’t miss future posts about the awesome future of the built environment: Shoegnome on FacebookTwitter, and the RSS feed.


  1. Phil Allsopp January 19, 2016
  2. Darren Bell January 19, 2016
    • Jared Banks January 20, 2016
      • Phil Allsopp January 20, 2016
  3. Phil Allsopp January 20, 2016
  4. Mark Senior January 22, 2016
  5. Steve Nickel January 23, 2016
    • Phil Allsopp January 23, 2016
  6. Steve Nickel January 23, 2016
    • Phil Allsopp January 23, 2016
  7. Steve Nickel January 24, 2016
  8. Scott Page January 24, 2016
    • Jared Banks January 24, 2016
      • Scott Page January 24, 2016
  9. Ferenc Traser January 25, 2016
    • Scott Page January 25, 2016
  10. Phil Allsopp January 25, 2016
  11. Pingback: A Tale of Exploding PDFs - Shoegnome February 21, 2017

Leave a Reply