The road to an efficient way of doing high precision solar analysis for large sites

One very important aspect to consider in the early planning phases of a new development, it's solar performance, since it affects both energy efficiency and the liveability of the area. There are multiple ways to calculate, quantize and visualize this, and it is often done to help inform the design process to ultimately create better living environments for people. For example, solar analysis can be used to better understand how the height of different building blocks can be varied to maximize the number of sun hours on courtyards, or to even out the solar gain between buildings for a better total energy performance.  

At first glance, it is no easy task to do this optimization, because we first need to find a way of knowing how much sunlight each building receives for a certain configuration before we can do any sort of optimization. This might seem like a challenging task, but when you think about it, the amount of daylight any surface receives depends on just a few factors:

- Its position and orientation 3-dimentional orientation,

- any obstructing objects that may shadow the surface,

- and the position of the sun.

Since a building façade is essentially a collection of surfaces facing different directions, we can use this simplified model to calculate the light/shadow map of a building if we know these three things for each point on the building. So, let’s break it down!

In Hektar, the location and orientation of each building element is given in the model, so we don’t have to worry about that.

Obstructing objects can in our case be anything from trees and other buildings to the topography of the ground at the specific location that may block sunlight from reaching the façade. In Hektar, we get a lot of this data for free since the models are always presented in their context together with any neighbouring buildings and with correct elevation in relation to the topography of the site.

Here, we also need to keep in mind that it’s not only about the obstruction effect that existing buildings has on what’s being developed, but also about how the new development affects the existing area. Hence, we’d also like to include this effect in our sunlight calculation model.

The third aspect is the sun’s position. Since the sun follows a predictable path at any specific location, if we also know the time and the date, we can calculate the exact sun position in relation to the building model. However, if we for example want to know the average number of sun hours in a day at a specific point in our model through the year, it’s not enough to only do this calculation for just one sun position. But the sun’s position loops every year, so we can estimate this value to any wanted precision (keep this in mind, it will be important later) by making binary shadow calculations for each point in the model with a set of sun positions that is representative of all sun positions throughout the year.

In theory, we have all we need to do this calculation for every point in the model to get a map of the solar performance of a certain proposed configuration of the development. But how do we perform the actual calculation when we have these parameters set?

Well, one way to think about it is that the sunlight that the building receives comes in the form of rays. These rays are essentially parallel since the sun is so faraway from us. This is where the first hack comes in! With this simplification, we can do the calculation by flipping the ray’s origin and direction and get the same result. So, what we do is to send out rays from each point in the model in the direction towards the sun. If the ray intersects any other part of the model, the point is in shadow for that specific sun position, and by extension at that specific time and date. This method is a simplified version of what is known as ray tracing and is used heavily in computer graphics and gaming to create realistic scenes.

Now we have everything we need, and we just need to carry out the calculation! But there is still one small problem, ray tracing is a demanding computation, and we need to do this for many sun positions for every point in a large model. Without optimizations, this will be way too slow for a web application like Hektar. So now for the second hack – parallelization!

The sun value for each point in the model isn't dependent on the sun values for the other points in the model, just the three factors we listed before. This means that we don’t have to wait for the computation for one point in the model to finish before we can start calculating the value for the next point. Remember I said ray-tracing is used heavily in gaming? Most modern computers have a graphical processing unit, a GPU, that is optimized for this sort of parallel computations and by utilizing this we can make these calculations A LOT faster than it would be to run them sequentially.

But this is still not enough, we still need another hack. If we want to make a high precision calculation, we’d ideally want to calculate the values with the same resolution as the screen to get the best result if we want to visualize it as a colour map, for example. To do this, we need to make the calculation itself much more efficient. The answer is still in the ray-tracing algorithm. The most naïve version of this algorithm checks for intersections with each surface in the whole model. But if we think about it, we don’t really have to do this for every single surface in the whole model to be sure there’s no intersection with the ray. For example, on average, half of the surfaces will be behind the rays' origin and does not have to be intersection-checked at all.

To reduce the number of unnecessary checks, we can create a bounding volume hierarchy for our model that we use for intersection checks. What this means is that we divide the model into cubes that then and subdivided into smaller and smaller cubes that contain the full geometry of the model. The insight here is that if the ray does not intersect one of these cubes, neither will it intersect any of its children. This might sound like a small optimization, but the fact is that for a complex model like in Hektar, it makes all the difference. It reduces the time complexity from O(N^2) to O(NlogN) where N is the number of faces in the model. This means that for a model with 100 000 vertices, this takes the computation time down from around 30 minutes to 0.3 seconds if performed on the same computer.

‍

‍

Now we have all we need to make a beautiful colour map of the sun performance of a neighbourhood in no-time! We’ve built this functionality into Hektar so you don’t have to worry about bounding volume hierarchies or sun positions at certain dates. This is one of the main goals of Hektar, to make complex tasks accessible and fun to use. Because we are certain that if we take away some of the barriers of using computational design as a decision tool in early-stage development it will lead to more adopters’ better insights, and ultimately better cities!

‍

So what are you waiting for? Create a free account and start using Hekar today!  

Sources and further reading:

https://github.com/mourner/suncalc

https://github.com/gkjohnson/three-mesh-bvh

https://www.khronos.org/opengl/wiki/Fragment_Shader

https://www.w3.org/TR/webgpu/

‍

‍