Arcol is the browser-based design tool for buildings, letting architects and contractors collaborate directly on early project definition and ideation, comparing trade-offs and options in the earliest phases of the design process. We recently launched an integration with the 3d modeling tool Rhino, allowing our users to create arbitrarily complex building shapes and stream those into Arcol for evaluation - floor plans, metrics, site layouts, and more.

We talked previously about the process of importing arbitrary 3d models, cleaning up messy and broken geometry to allow users to model anything they can imagine without compromising on their workflow.

But what comes next? Once the user has imported the model, they will split it into floors and begin breaking those floors down into floor plans - individual units and rooms - to demonstrate how the building might satisfy particular unit mix requirements or be used in practice by its owner. A critical step in this visualization is that the resulting buildings must be able to draw the colors of the floor plans it contains correctly, like so:

Complex Buildings

In Arcol, we call this workflow “complex buildings”. Their shapes can be arbitrary and the models can contain tens of thousands of triangles, but editing their floor plans needs to feel immediate. The rendering challenge we faced was keeping the building’s shape and all the spaces within it visible and responsive, even as the design changes.

This challenge led us to research and experiment with several approaches, and ultimately, to invent a new approach to rendering buildings that lets us draw scenes and diagrams at interactive speeds, without needing to recompute the building geometry, even for truly complex buildings with millions of polygons.

Traditional Approach

Floor plans in Arcol define volumes in space for each room, and we want to intersect these with the building shell to determine the correct exterior coloring to apply. The traditional way to approach this problem in CAD is through Constructive Solid Geometry. This approach would geometrically compute the intersection between the shape of the building shell and the internal functions and area types defined by the floor plans, resulting in the geometry of these overlapped regions. This was a lot of computation to generate a detailed model that, ultimately, we didn’t actually need.

We’re still calculating the cross-section analytically for each floor against the building mesh, so we can accurately calculate metrics and areas for Arcol’s measurement and reporting features. But for interactive display we want something that can update in real-time.

Additionally this approach would need to handle lots of cases that are difficult for CSG algorithms, including building masses that look reasonable but have invisible problems like tiny gaps or duplicated edges. We needed something that would work with even with a highly tessellated curved surface, photogrammetric reconstruction, or lidar scanned building model. We tried some remeshing and shrink-wrap approaches to preprocess the geometry, but that resulted in messy geometry, rounded off corners, and weird shading even at unreasonably high triangle counts. Ultimately, we realized that using CSG on dense models was too slow to allow our goal of interactive editing.

One interesting approach is the idea of using “stencil CSG”. This works not by figuring out where the meshes intersect geometrically, but by drawing them using the stencil buffer to mask one shape with another. By carefully rearranging the operations, you can render an arbitrary CSG tree with this approach, and this has been used by tools such as OpenCSG to render complex CSG scenes.

This seemed promising, however, we’re still drawing each room or object separately. So in this case, we want to draw the building shell (purple sphere) with the color from the interior volumes that it overlaps, but since the shell is still a single draw, even though it’s clipped correctly, it still has a single material color, taken from the shell’s draw call not the extrusion.

While this method is simple to implement in isolation, it’s harder to make it work in the context of a larger scene. This approach resulted in a lot of render passes per building and was difficult to integrate with the rest of the scene geometry like the site context buildings, imported models, and other scene buildings.

Z Depth Masking

We realized that we don’t need to compute arbitrary CSG volumes here. Our problem was more specific: we just want to draw the interior regions where they are overlapping the building shell, and we only need the color from the region, as the rest of the information can come from the building shell.

The idea was that instead of using a single stencil pass to mask where a volume was, we could render a pair of z-depth images: both the nearest z-depth (a typical z-buffer), and also one for the furthest backfacing depth.

The Z-Depth masking in detail:

• Discard fragments closer than the Near Depth.

• The far depth is used to mask regions outside of the object silhouette.

• Keep fragments within the depth interval. These are drawn at the extrude region depth so the regions properly occlude each other.

• Color comes from the extrusion volume being drawn, but normal (for lighting) comes from the gbuffer normal (this will be incorrect for interior fragments, but will look correct for the closest fragment which will be the only one visible in the final image).

• Extrudes are drawn “inside out” so the closest region will be visible and they won’t zfight each other.

• After drawing all regions, the shell is drawn again in a “depth only” mode, to fix up the zbuffer so that the rest of the scene can be drawn as usual.

Once we have these buffers, we can render the interior volumes, and by comparing their fragment depth to the pair of depth buffers, we can determine which fragments overlap the building shell in 3d space: If the fragment is closer than the far-depth, and further than the near-depth then we draw it. If not, it gets discarded in the shader. If there are gaps or holes inside the building volume, that’s okay because these will always get overdrawn by closer volumes.

These are drawn “inside out” with flipped normals, since the extrusion volumes will extend beyond the building shell, so the “backfaces” of a volume will show up, even if the front faces may be clipped away.

This draw call will give us the desired color for each region, but if we drew this directly it would just look like cubes clipped to the building silhouette. However, we’re already rendering a pre-pass which includes normals for other visual effects like SSAO, so by using that for the shading and using the color from these clipped volumes, we’re able to draw the building shells with proper lighting. Finally, the building shell is rendered one last time to the main depth buffer only, allowing the building to be integrated into the rest of the scene and properly intersect other objects like terrain and imported meshes.

This approach worked. A 2.8M triangle scanned model of a Rhino statue (get it?) could be rendered in milliseconds on my laptop, even when region volumes are changing in real-time.

Prototype to Production App

I think one of the exciting things about Arcol being a small but powerful startup is we can move quickly. If something like this is proven to be a good idea in a prototype, there are no obstacles to getting it into production and into the hands of our customers.

This approach is now live in Arcol. Architects can bring in complex forms from Rhino, create floor plans, and see their edits reflected immediately, even on large models. The response has been positive: the workflow that motivated this work is now in people’s hands.