Under the hood: 2D rendering in Archicad 26

[Steven Szennai]

This article aims to provide some insight into our 2D modernization project spanning across multiple Archicad versions. The focus will be on the changes in line rendering and its benefits.

As the title implies, the material is recommended for readers interested in the inner workings of the software to gain a better understanding of why it changed as it did over the years.

Terminology

Before I dive into the details, a short summary of the technical terms used:

• aliasing: discretization of vector data due to rasterization ("jagged edge/line")
• anti-aliasing: attempt to reconstruct vector data during or after rasterization
• API: software interface that provides a service to the application
• rendering API: an API specialized for rendering purposes (e.g. Direct3D, OpenGL, Metal)
• driver: provides a software interface for a hardware device
• shader: small program running on the Graphics Processing Unit (GPU)

History of cross-platform functionality

While Archicad itself is cross-platform, the underlying source code that handles rendering wasn't for a very long time. Early attempts were made in Archicad 22 with the introduction of an extensible software interface backed by OpenGL 3.3. I'm going to refer to this as (Archicad's) GPU interface.

During the development of Archicad 25 we started a modernization project (first on macOS), which had two goals:

• transition the low-level rendering to Apple's Metal API (since OpenGL had become deprecated)
• research a new anti-aliasing method in order to reduce the GPU memory footprint

Another argument supporting the latter was the numerous driver crashes caused by the then current anti-aliasing solution (MSAA).

---

The next milestone of this modernization (with Archicad 26 as target) was to renew our hybrid Direct3D-OpenGL drawing infrastructure on Windows (I'm going to refer to it as legacy implementation). Here we had additional concerns:

• the Direct3D part (2D) was a completely isolated implementation, thus it was hard to maintain or build upon
• wanted to adopt the same looks and behavior that we implemented on macOS
• wanted to form a basis for other new technologies (e.g. hardware-accelerated text rendering)

The decision we made was to get rid of the legacy implementation, and reimplement the Direct3D functionality under the platform-independent GPU interface. This effectively means that starting with Archicad 26 we have a truly cross-platform implementation which we can improve without dealing with the rendering API differences.

Shader-based line rendering

Without the gobbledygook, the anti-aliasing part is just a Gaussian function (so-called bell curve) perpendicular to the line's direction. Note that I'm using the word "line", while in fact they are rectangular polygons. From left to right: aliased, MSAA, shader-based rendering

The strength of the algorithm is that it can render round caps (in fact any type of cap) for free. In the legacy implementation caps were done by calculating the actual geometry, which meant unnecessary memory usage and segmented look at high zoom levels.The legacy implementation (left) had to manually generate rounded caps, whilst the new one (right) calculates them during rasterization

It also saves the memory that would come directly from MSAA (i.e. the driver doesn't have to allocate memory for subpixel samples).

Afterword

The new Direct3D implementation automatically detects the stronger GPU on multi-GPU systems. If desired, this feature can be turned off by setting the following registry key to zero:

HKCU\SOFTWARE\Graphisoft\Archicad\Archicad XXXX\Graphix\AutoDetectGPU

This is recommended for laptop users when the device cannot be connected to the power outlet for long periods of time. Note that Windows' Power saving setting might not have an effect on its own.

Generally it is not advised to touch the registry. Should you be unsure, contact your local technical support for a step-by-step guide.

[Barry Kelly]

You mention 'round caps' to the ends of the lines.

I think most of us here would prefer square ends.

Of course the round ends are not so noticeable with thin lines (pens), but with thicker lines it can become noticeable.

We would also love the ability to set the line thickness from the side of a line rather than the centre.

That way we won't have the silly situation where lines of abutting elements half cover each other.

Can of worms - open. 😀

Barry.

[William Yan]

Cool!  I have found that the anti-aliasing effect of the diagonal line looks better than before.

[Professor Pickle]

A very useful article, at least to me. Thanks for sharing this. It's always great to hear about what's going on under the hood.

[Eduardo Rolon]

Prefer Round Caps to balance out @Barry Kelly 

[Laszlo Nagy]

+1 on everything Barry said.

I think one particular situation in that case is when we have two lines meeting at a very acute angle. If the angle is very small and we have a wide lineweight, the outer edges of the line thickness can extend very far from the actual corner of the two lines' axes. In that case, the ability to set line width to extend "inward" would be the solution.

It would also be important when defining Composites so for example, if we have a Core with a thick outline, and a thin Skin right next to it, the Core's boundary line width does not overlap the thin Skin.