Content uploaded by Timur Dogan

Author content

All content in this area was uploaded by Timur Dogan on Aug 13, 2017

Content may be subject to copyright.

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

430

Fast and Robust External Solar Shading Calculations

using the Pixel Counting Algorithm with Transparency

Joel Hoover, Timur Dogan

jah552@cornell.edu, tkdogan@cornell.edu

Environmental Systems Lab, Cornell, Ithaca, New York, USA

Abstract

External solar shading calculations play an important role

in energy models for buildings. Current simulation

software implements polygon clipping algorithms for

these calculations. However, polygon clipping suffers

from several limitations, such as high computational costs

and, for complex geometry, robustness issues. These

weaknesses are a major bottleneck for the simulation of

large scale urban building energy modelling (UBEM).

This paper introduces a graphics hardware accelerated

shading algorithm that uses pixel counting and supports

transparency. The algorithm has been integrated in

EnergyPlus and proves to be on average 2 times faster

than EnergyPlus’s shading algorithm, while maintaining

an accuracy of 0.01.

Introduction

The current trend of population-growth and urbanization

requires construction and densification of urban centers

globally. With 33% of carbon emissions coming from

buildings, this development is worrisome, but also

presents a great opportunity to mitigate climate change

through effective use of solar energy and energy

efficiency measures in buildings. One crucial component

of sustainable and passive environmental performance

driven design is solar control and effective use of the suns

energy in order to reduce heating and cooling loads by

utilizing passive solar gains in the winter and effective

solar shading in the summer (Olgyay, Olgyay, and others

1976).

Recent developments in the field of dynamic building

simulation have provided holistic, well-validated building

energy simulation frameworks such as EnergyPlus

(Crawley et al. 2001), TRNSYS (Klein 1979) and others

(Crawley et al. 2008) that can predict most relevant

environmental performance indicators. Such software

allows designers to optimize a buildings orientation and

solar exposure to minimize HVAC energy consumption.

This optimization is even more important at the urban

scale – where building volume, position and orientation

are determined – and the impact of these design decisions

affect many buildings.

Since the solar environment greatly impacts a building’s

energy performance, reliable solar shading calculation is

one of the most important components of these tools.

Solar shading consists of three components: direct beam

radiation, indirect diffuse radiation, and reflected

radiation. In this paper, we are only concerned with beam

radiation. The equation for calculating the solar heat gain

from direct beam radiation is

𝑄beam = 𝛼𝐼b

𝐴s

𝐴t

cos 𝜃 (1)

where 𝑄beam = solar heat gain per unit area, 𝛼 = fraction

of solar absorption of the surface, 𝐼b= intensity of direct

beam radiation, 𝐴s= sunlit surface area, 𝐴t= total

surface area, and 𝜃 = angle between sun’s rays and the

surface’s normal vector (EnergyPlus Development Team

2016). The most computationally intense part of this

equation comes from the 𝐴s component, which requires

consideration of the surface’s context and determining

what amount of the surface is exposed to the sun and not

hidden in the shadow of another surface. Rather than

calculate 𝐴s directly, the term (𝐴s𝐴t)

⁄cos 𝜃 is often

calculated instead. This value is called the projected sunlit

surface fraction (PSSF), and our focus is to efficiently

calculate this value.

There are two general approaches to finding the PSSF at

any time during the simulation. The EnergyPlus method

is to calculate the PSSF for each surface of the building

for each simulation time step throughout the entire year.

The other method, employed by TRNSYS, is to divide the

sky into many small sky patches, and calculate the PSSF

of each surface as if the sun was in the center of each sky

patch. Then, to get the PSSF for any time step, the PSSF

of the sky patches around the sun position are averaged.

There are advantages and disadvantages to both

approaches, but both require an underlying algorithm to

calculate the PSSF values for the sun at a given location

in the sky.

There are four classes of algorithms that can be used to

calculate PSSF values: Trigonometric algorithms for

awnings, fins, and horizons; ray tracing; polygon

clipping; and pixel counting.

First, trigonometric algorithms allow for the PSSF to be

calculated quickly and exactly, but only work for very

simple shading devices, such as overhangs and wing walls

(McCluney 1990). While these algorithms are still

implemented in modern simulation software, namely

TRNSYS, their strict requirements on the shading

geometry limit their application. For complicated shading

systems or for contextual shading, such as for buildings

on the opposite side of the street, another shading

algorithm must be used.

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

431

Second, polygon clipping algorithms is a class of

geometric algorithms that calculate the PSSF accurately,

and unlike trigonometric algorithms, they do not place

overly strict restrictions on the geometry. As such, they

have been implemented and are still widely used for

calculating PSSF. The general outline for a polygon

clipping algorithm is as follows: First, take all the surface

and all the shading geometry in the scene, and project

them onto the plane perpendicular to the direction of the

direct beam radiation. Then, for each shading surface in

the scene, the projected polygon is “clipped” from the

projected polygon of the surface. Finally, take the area of

the resulting polygon and divide it by the area original

surface to get the PSSF. For a more comprehensive

description of the various polygon clipping algorithms,

refer to (Hiller, Beckman, and Mitchell 1996). Polygon

clipping has many limitations, however, which makes it

less than ideal. It still places some restrictions on the

geometry: for most algorithms, polygons must be convex,

and robustness issues can occur when multiple shadows

overlap, which can cause the algorithm to fail even for

relatively simple geometry. Further, current

implementations are extremely slow, with the polygon

clipping shading algorithm being one of the most time-

consuming component of the simulation.

Third, ray-tracing based methods directly simulate

individual rays of sunlight falling on the surfaces

bouncing around the scene. Because the simulated rays

are independent and can be reflected, ray-tracing can

simulate not just direct beam radiation, but also reflected

radiation. Therefore, it is a promising approach to

improve accuracy of both direct and diffuse calculation

methods, as well as distribution of sunlight on the interior

of the building. However, since these methods need to

simulate a large number of independent rays to get

accurate results, they end up being computationally

expensive and are therefore less suitable for urban/early

design applications. EnergyPlus calculates that the diffuse

component using a coarse ray casting method, as opposed

to full ray tracing, and assumes that this is sufficiently

accurate. Hence, the computational overhead required for

ray-tracing is only justifiable in special cases where

propagation of the diffuse radiation plays a significant

role.

Finally, pixel counting algorithms allow for fast

approximation of the PSSF through computer graphics

based methods: they approximate the PSSF by rendering

the scene to an image buffer and counting the number of

pixels visible from the suns viewing angle to estimate the

exposed area of each surface (Yezioro and Shaviv 1994).

The most recent implementation of such an algorithm is

described by Jones et al. (Jones, Greenberg, and Pratt

2012) and it is shown that shading calculations can be

accelerated significantly without sacrificing accuracy.

The pixel counting approach can handle complex

geometry, including elaborate shading devices, without a

loss in accuracy, which alleviates the current necessity to

oversimplify the energy model’s input geometry. Jones et

al.’s implementation is unfortunately not publicly

available. Another limitation of their implementation is

the lack of transparency support. Transparency is relevant

in early building and urban design to model vegetation

coverage, which would need prohibitively complex

geometry to model exactly, but can be approximated by

only a few transparent polygons. Vegetation also often

has seasonal changes, which can easily be modelled by

assigning a schedule to the transparency. Additionally,

shading systems that are either change dynamically or

include fritted or metal mesh facades can be modeled

using transparency, which is useful for efficiency

purposes. In urban design, this level of detail is generally

not modelled geometrically due to CAD software

limitations and the large burden on the designer. Using

simple surfaces with transparency keeps the polygon

count manageable, while still providing a close

approximate of more detailed designs. Hence, this paper

describes a publicly available solar shading simulation

tool that is GPU accelerated, supports transparency, and

can be used in conjunction with EnergyPlus.

Figure 1: Capture of the pixel counter’s internal color

buffer for Case #8 at 15% (left), 40% (middle), and 80%

(right) transparency.

Figure 2: Urban Test Case #9

Figure 3: ISO Validation Cases #1 (left) through #4

(right).

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

432

Methods and Implementation

The Pixel Counting Algorithm

Our pixel counting algorithm for calculating PSSF is

inspired by the algorithm proposed by Jones et al. The

general outline of this algorithms is as follows: first, the

entire scene, except for the surface of interest, is rendered

(drawn) to an image buffer. Then, an OpenGL query

object is generated, and the surface of interest is rendered

to the buffer. (It is important to note that depth

information is retained as part of the image buffer, so that

anything in the scene that is in front of the surface will

occlude the surface at the pixels of overlap, even though

the surface is rendered later.) Next, the query object is

read, yielding the number of pixels in the buffer that were

affected by the surface of interest. Finally, the pixel count

is converted into area, from which the PSSF can be

calculated. This entire process is then repeated for every

surface of the building. The renders are performed with a

special setup: the camera is configured so that the

projection is orthogonal (to model the sun’s rays as being

parallel), that the angle of the rays correspond to the sun’s

position in the sky, and that the surface of interest takes

up as much of the render buffer as possible. Finally, each

surface is given a unique color as an identifier.

For our algorithm, we make three major modifications.

First, instead of scaling the render so that the surface of

interest covers the entire buffer, so that each surface has

its own transformation, the render is scaled such that all

surfaces are visible with only one transformation. This

allows the entire scene to only be rendered once, rather

than needing the entire scene to be rendered again and

again for every surface. To find the number of pixels in

the final buffer that belong to a given surface, we activate

an OpenGL query object, draw the given surface again,

and then read back the result of this query object. These

queries are performed for every active surface in the

scene. Because we need all the active surfaces to be

contained in the final render, we can no longer perform

the per surface scaling à la Jones et al.’s algorithm.

However, our method greatly reduces the number of

renders required, as we only need one per sun position

rather than one per active surface per sun position.

Our second modification is to add probabilistic model of

transparency as follows: we apply a shader that will

pseudo-randomly discard pixels from triangles as they are

being rendered, where the probability of a pixel being

dropped is equal to one minus the opacity of the pixel.

That is, a triangle with opacity 1.0 will have no pixels

discarded (fully opaque), a triangle with opacity 0.0 will

have all pixels discarded (fully transparent), and a triangle

with opacity 0.5 will have approximately half of its pixels

discarded (50% transparent). The pseudo-random

algorithm in the shader is seeded with the id of the surface,

so that same surface rendered twice will have the exact

same pixels discarded. A visualization of the transparency

in action can be seen in Figure 1, which are captures from

the pixel counter for test Case #8.

For our final modification, we add a stencil buffer to

handle intersecting surfaces. Since we place no

restrictions on the geometry, it is possible for two surfaces

to intersect each other, and the pixels at the intersection

will be counted twice. To resolve this issue, we add a

stencil buffer to our render target; then during the second

query pass, drawing to a pixel sets the stencil buffer at that

pixel to 1 and cause further draws to that pixel to be

discarded. Thus, each pixel will only be counted once.

Implementation

We have implemented our algorithm in C# using the

OpenTK bindings to OpenGL. It requires OpenGL 2.0 or

higher, and the extension EXT_Framebuffer_Object must

be supported. We have also designed several Grasshopper

components that allow our algorithm to be used in the

Rhino CAD software. Finally, we have a modified version

of EnergyPlus that reads in the shaded fractions from a

file, allowing us to perform energy simulations using our

pixel counting generated values. The implementation is

available at es.aap.cornell.edu. The pixel counting

codebase is split into several sub-projects: ShadingBase,

PixelCountingLib, PixelCountingTest, and

PixelCountingPlugin. ShadingBase provides as set of

classes that abstract away certain details of the pixel

counting code, such as geometry specification and error

reporting. This would allow, for example, alternate pixel

counting algorithm, or even a polygon clipping algorithm,

to be implemented with the same interface, allowing easy

comparison between the two algorithms.

PixelCountingLib is the actual implementation of our

pixel counting algorithm, and implements the interface

given in ShadingBase. PixelCountingTest contains a few

test cases for the PixelCountingLib implementation.

Finally, PixelCountingPlugin provides the Grasshopper

components that allow our algorithm to be used in Rhino.

To control the number of pixels used for the render buffer,

our implementation calculates the optimal size given a

“resolution” from the user. A resolution is given in area

(in cm2), and defines the maximum area that a pixel can

have. Once the geometry is given, the implementation

calculates the number of pixels needed to render the

geometry and then uses that number of pixels internally.

Testing Methodology

We test our implementation against 9 test cases, with each

case evaluated for accuracy, speed, and robustness.

Accuracy is validated against analytic values (if

available), and/or against the shaded fractions generated

by EnergyPlus. Each test case is evaluated at the

resolution sizes of 4000cm2, 400cm2, 40cm2, and 4cm2.

Test cases #1-#6 are taken form an ISO standard for

shading calculation validations (“ISO 13791:2012-03

Thermal Performance of Buildings - Calculation of

Internal Temperatures of a Room in Summer without

Mechanical Cooling - General Criteria and Validation

Procedures” 2012). Test cases #1-#4 are illustrated in

Figure 3. We validate our implementation against the

values for the sunlit fraction at various sun positions as

given in the standard. We additionally validate and speed

test our implementation against EnergyPlus by comparing

the PSSF values for every one hour time step in a year

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

433

simulation at Phoenix, Arizona and at Anchorage, Alaska,

for each case. Additionally, both validation tests are done

at the resolutions of 4000cm2, 400cm2, 40cm2, and 4cm2.

Test case #7 is a sequence of small cylinders outside of

the standard south facing building in test case #1-#3.

There are 75 cylinders, each 4m long and with a 20cm

diameter. They are equally spaced vertically to take up the

entire 3m height of the building, and are placed 0.1m

away from the south wall. We then select the sun positions

that are due south at elevation 0º, 5º, and 10º elevation and

use pixel counting at various resolutions to find the PSSF.

Additionally, a timing test is performed for the pixel

counting implementation to calculate the PSSF at 4000

random sun positions. This test will allow us to determine

how the pixel counting algorithm handles extremely fine

geometry, what resolution is needed to attain satisfactory

accuracy, and how well the implementation handles a

large number of shading surfaces.

Test case #8 is again the standard south facing building

and window from cases #1-#3, but we add a transparent

enclosure that extends 2m from the south-facing wall. We

then run an EnergyPlus simulation at Phoenix, Arizona

and at Anchorage, Alaska, and use the hourly PSSF values

to validate our transparency implementation. The

enclosure is tested at 0%, 15%, 40%, and 80%

transparency (where 0% is fully opaque and 100% fully

transparent), and the resolution for our pixel counter is

tested at 4000cm2, 400cm2, 40cm2, and 4cm2. This test

will compare the accuracy of our transparency

implementation to the EnergyPlus transparency

algorithm. Test case #9 is a full scale urban model

containing 121 buildings in a 600m by 800m block. The

model is illustrated in Figure 2. Windows are placed on

each wall of all buildings to cover 95% of the width and

95% of the height of the wall. We then perform a yearly

EnergyPlus simulation at Phoenix, Arizona and at

Anchorage, Alaska and compare the resulting PSSF

against our pixel counting implementation at resolution

4000cm2, 400cm2, 40cm2, and 4cm2. This test will

function as a stress test for our implementation, testing if

it is robust enough to handle an entire urban scene with

many active and shading surfaces.

All pixel counting tests and EnergyPlus simulations were

run on a Mid-2014 MacBook Pro with 2.6 GHz Intel Core

i5 with 8GB RAM with an Intel Iris 1536 MB. The only

exception is Case #9, where the EnergyPlus simulations

were performed on a Windows 10 Desktop with a 3.0

GHz Intel i7 6950x and 64 GB RAM. The version of

EnergyPlus used is 8.5.0.

Results

The results from the DIN EN ISO 13791:2012-08

validation are shown in Figure 4. Additionally, the

acceptable error range as specified by the standard is

highlighted in green in the graphs. In graphs (a) and (b),

we see that the errors at 4000cm2 and 400cm2 are well

outside the acceptable tolerances and clearly fail

validation. The 40cm2 resolution in graph (c) almost

passes, but fails at the 7:30 time step and Case #6 at noon,

and Case #2 pushes the bounds from 8:30 to 9:30. Finally,

at the 4cm2 resolution in graph (d), all errors are well

within the tolerance, except again for at 7:30 and Case #6

at noon.

While these results seem to indicate that none of the

resolutions tested are accurate enough, we note that all the

significant errors at 4cm2 and 40cm2 occur while the sun

is at low angle relative to the window. At such low sun

angles, very little radiation is hitting the window, and so

large errors in the sunlit fraction of the window result in

relatively small errors in the amount of radiation received.

For example, the south-facing windows in Cases #1-#4

would receive only 7.7% of the radiation at 7:30 than at

noon, and so a 4% error in sunlit fraction that would be

within tolerance at noon is equivalent to an almost 50%

error in sunlit fraction at 7:30. Likewise, for Case #6 at

noon, the sun position is in the plane of the window, so no

radiation will fall on the window, and so any value given

for sunlit fraction is meaningless, as it will be multiplied

by 0 before used for any further calculations. Thus, the

large apparent error in Case #6 at noon is meaningless.

Because of these issues with sun position at low angles,

we use PSSF instead of sunlit fraction in our further

accuracy evaluations, as it is directly proportional to the

amount of radiation hitting a surface.

The results of the validation of Cases #1-#6 against

EnergyPlus are presented in histograms in Figure 5 (a)-

(d), and the mean and standard deviation in the errors are

reported in Table 1. The times in which the PSSF is zero

have been excluded. We see that the distribution of errors

roughly follows a normal distribution and is centered

around 0. At 40cm2 resolution, all the errors are within

0.05, and the 4cm2 resolution, within 0.01. However, the

Anchorage location has consistently higher error than the

Phoenix location. Figure 6, which plots error against sun

elevation, explains why: both the Phoenix and Anchorage

locations have very similar error distributions at a given

sun elevation, and that lower sun elevations has tends to

have larger error than higher sun elevations. Since

Anchorage has lower sun elevations than Phoenix,

Anchorage has a greater average error in the PSSF.

The timings for Cases #1-#6 are presented in Table 2. To

generate the EnergyPlus timing, two simulations were run

for each case, once by running EnergyPlus by

recalculating shading every day, and one by recalculating

shading one a year, and then the difference in timings

between the two runs is reported. The EnergyPlus shading

calculations took between 1.82 and 2.12 seconds. By

contrast, the pixel counting simulations took between 0.68

and 0.89, except for the 4cm2 resolution for Cases #4 and

#6, which took 1.4 and 1.5 seconds, respectively.

For small cylinder Case #7, a simulation using

EnergyPlus was attempted. However, due to the

extremely high polygon count of the cylinders,

EnergyPlus did not advance past the “Initializing

Simulation” phase in over 24 hours, so the simulation was

aborted. Luckily, there is an approximate analytic solution

to this shading problem if we limit the sun position to be

due south with an angle of elevation 𝜃, from the horizon

at 𝜃 = 0° to the elevation where the cylinders block all

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

434

Figure 4: The error in the ISO validation test at each

sun position during the sample day at resolutions (a)

4000cm2, (b) 400cm2, (c) 40cm2, and (d) 4cm2.

Figure 5: Histograms of the error distribution against

EnergyPlus values for all Cases #1-#6 at Phoenix and

Anchorage simulations at resolutions (a) 4000cm2, (b)

400cm2, (c) 40cm2, and (d) 4cm2.

-1

-0.75

-0.5

-0.25

0

0.25

0.5

0.75

1

7 8 9 10 11 12

Error in Sunlit Fraction

Time

Errors in ISO Validation at 4000cm2 Resolution

Case 1

Case 2

Case 3

Case 4

Case 5

Case 6

-0.5

-0.25

0

0.25

0.5

7 8 9 10 11 12

Error in Sunlit Fraction

Time

Errors in ISO Validation at 400cm2 Resolution

Case 1

Case 2

Case 3

Case 4

Case 5

-0.2

-0.15

-0.1

-0.05

0

0.05

0.1

0.15

0.2

7 8 9 10 11 12

Error in Sunlit Fraction

Time

Errors in ISO Validation at 40cm2 Resolution

Case 1

Case 2

Case 3

Case 4

Case 5

Case 6

-0.075

-0.05

-0.025

0

0.025

0.05

0.075

7 8 9 10 11 12

Error in Sunlit Fraction

Time

Errors in ISO Validation at 4cm2 Resolution

Case 1

Case 2

Case 3

Case 4

Case 5

Case 6

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05 4000cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05 400cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05 40cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05 4cm2Resolution Phoenix Anchorage

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

435

Figure 6: Plot of error in PSSF vs. sun elevation for ISO

Case #3 at 40cm2 resolution at Phoenix and Anchorage.

Figure 7: Plot of error in PSSF vs. resolution for small

cylinder Case #7 at 0º elevation.

Figure 8: Plot of error in PSSF vs. resolution for small

cylinder Case #7 at 0º, 5º, and 10º elevations over

resolutions 100cm2 to 0.01cm2.

Table 1: EnergyPlus validation errors for Cases #1-#6.

Place

Resolution

Mean

Std. Dev.

Phoenix

4000 cm2

-0.0144

0.0970

400 cm2

0.0058

0.0363

40 cm2

-0.0014

0.0109

4 cm2

-0.0001

0.0033

Anchorage

4000 cm2

-0.0496

0.1211

400 cm2

0.0109

0.0464

40 cm2

-0.0018

0.0142

4 cm2

0.0000

0.0041

Table 2: The timing results of ISO Test Cases #1-#6 at

Phoenix for EnergyPlus shading calculations and pixel

counting at various resolutions.

Case

Energy

Plus

Pixel Counting

4000cm2

400cm2

40cm2

4cm2

#1

1.90

0.70

0.69

0.76

0.80

#2

2.06

0.68

0.74

0.74

0.72

#3

1.82

0.72

0.68

0.89

0.78

#4

2.12

0.71

0.69

0.76

1.40

#5

1.98

0.73

0.73

0.67

0.82

#6

1.82

0.70

0.72

0.72

1.50

Table 3: The accuracy statistics for Case #8 at various

resolutions.

Resolution

Transparency

Mean

Std. Dev

4000 cm2

0%

0.0084

0.1395

15%

0.0062

0.1355

40%

0.0051

0.1207

80%

-0.0024

0.0777

400 cm2

0%

0.0050

0.0446

15%

0.0049

0.0434

40%

0.0029

0.0400

80%

-0.0001

0.0253

40 cm2

0%

-0.0015

0.0138

15%

-0.0007

0.0136

40%

-0.0010

0.0129

80%

-0.0004

0.0082

4 cm2

0%

-0.0001

0.0044

15%

0.0003

0.0044

40%

-0.0001

0.0040

80%

0.0000

0.0026

-0.05

-0.04

-0.03

-0.02

-0.01

0

0.01

0.02

0.03

0.04

010 20 30 40 50 60 70

Error (PSSF)

Sun Elevation (deg)

Case #3 at 40cm2Resolution

Phoenix Anchorage

-0.06

-0.04

-0.02

0.00

0.02

0.04

0.06

0.08

0.10

0.12

2540557085100

PSSF Error

Resolution (cm2)

Small Cylinder Case at 0°Elevation

-0.12

-0.10

-0.08

-0.06

-0.04

-0.02

0.00

0.02

0.04

0.010.1110100

PSSF Error

Resolution (cm2)

Small Cylinder Case at 0°, 5°, and 10°Elevation

0° 5° 10°

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

436

Figure 9: Histograms of the error distribution against

EnergyPlus values for all Cases #1-#6 at Phoenix and

Anchorage simulations at resolutions (a) 4000cm2, (b)

400cm2, (c) 40cm2, and (d) 4cm2

Table 4: The timing results of Urban Case #9 for

EnergyPlus shading calculations and pixel counting at

various resolutions.

Piecewise Model

Full Model

EnergyPlus

14758 s

—

Pixel Counting

4000 cm2

1789 s

852 s

400 cm2

1975 s

1020 s

179 cm2

—

1218 s

40 cm2

3816 s

—

4 cm2

20930 s

—

Table 5: Statistics on errors for Cases #9.

Place

Resolution

Mean

Std. Dev.

Phoenix

4000 cm2

0.00005

0.0257

400 cm2

-0.00002

0.0105

40 cm2

-0.00001

0.0057

4 cm2

0.00000

0.0025

Anchorage

4000 cm2

0.00411

0.0595

400 cm2

-0.00002

0.0118

40 cm2

0.00000

0.0065

4 cm2

0.00000

0.0022

light at 𝜃 = 60°. This solution is presented in Equation 2

below.

𝑃𝑆𝑆𝐹 = cos 𝜃 − 1 2

⁄ (2)

This equation is, however, only an approximation, as it

does not account for cylinders near the edge of the

window that only part of the cylinder shades the window.

The maximum error is the proportion of the diameter of

the cylinder compared to the window height, which is

20𝑐𝑚 2𝑚

⁄= 0.01.

Figure 7 presents the error vs resolution for the sun at 0º

elevation for 100 resolutions between 100 cm2 and 27.8

cm2. Within these resolutions, the error fluctuates

between -0.049 and 0.105. Figure 8 presents the error vs

resolution for the sun at 0º, 5º, and 10º at 14 resolutions

between 100 cm2 and 0.012 cm2. At the coarse

resolutions, the errors are as large as -0.103, but as the

resolution increases, the error decreases down to errors

smaller than 0.01 for the smallest resolutions between

0.1 cm2 and 0.012 cm2. Together, these tests show that

small changes in resolution can lead to large changes in

error when the resolution is too coarse for the geometry,

but as the resolution increases, this variation decreases,

and the error can be bounded. Finally, for the timings

test of Case #7, it took the implementation only 37.6

seconds to perform the 4000 renders, which is extremely

good performance, as the cylinders are constructed of

about 1.6 million triangles.

For Case #8, Table 3 presents the mean and standard

deviation for the errors against the PSSF reported by

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1.E+06

1.E+07 4000cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1.E+06

1.E+07 400cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1.E+06

1.E+07 40cm2Resolution Phoenix Anchorage

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1.E+06

1.E+07 4cm2Resolution Phoenix Anchorage

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

437

EnergyPlus. We again see that the means are very close to

zero, and that the standard deviation decreases as

resolution increases. One interesting observation is that

the standard deviation is smaller for more opaque

surfaces, although this is likely due to the PSSF itself

being smaller, causing errors to naturally shrink as well.

Finally, we have Case #9. We had many issues attempting

to simulate the large urban model with EnergyPlus. First,

we attempted to run a simulation of the entire model, but

this simply caused EnergyPlus to crash. Next, we

generated a piecewise model, which simulated each

building individually, including as shading surfaces any

building within 150 meters. While a few of these

simulations took under 10 minutes, a majority took over

an hour, with some taking as long as 23 hours. In total, the

simulations took 55 days, 20 hours, and 21 minutes of

CPU time. In addition to the extremely long runtime,

many of the simulations reported “severe errors” during

the shading calculations, and that the “Shadowing values

may be inaccurate.” So, we performed one further

simplification to the piecewise model: only selecting as

shading surfaces walls that are within 150 meters and face

the center of the simulation building. This finally yielded

simulations that completed in a reasonable amount of

time, 19 seconds in the fastest case and 282 seconds in the

longest case. However, there was still one simulation that

reported severe errors during the shading calculations,

and 20 other files that, while not reported as severe,

produced warnings during the shading calculation that

indicate an error occurred while generating some of the

shaded fractions.

As opposed to EnergyPlus, the pixel counting

implementation had no issues with running a simulation

on the entire model. However, due to the hardware only

supporting up to 8192 pixel by 8192 pixel framebuffers,

in addition to the huge 500 meter by 700 meter model, the

pixel counter could only simulate up to 179 cm2

resolution. We also ran the pixel counter against the

piecewise model that EnergyPlus could simulate for the

accuracy comparison. The timings for these are reported

in Table 4.

Table 5 provides the statistics on error in the urban case

for each resolution. As for the ISO Cases, we again see

that the mean is extremely close to 0, and that the standard

deviation is larger for coarser resolutions. Figure 9(a)-(d)

provides histograms of the errors for each resolution using

the same bins as in Figure 5. Note that these histograms

are logarithmic on the vertical axis. The shape of the

distribution is again normal like, but there also seems to

be a slight left skew to the distribution, and it appears that,

for large errors, there are more negative errors than

positive. Furthermore, there are many errors at the

extreme edges of the histogram. These errors, along with

most of the moderate errors, originate from the 20

simulations that that produced the warnings during the

shading calculations. If we exclude these simulations, the

errors are much more tightly bound, especially for the

finer resolutions.

Discussion

The results in the previous section are overall very

positive. For example, for Cases #1-#6, our

implementation can calculate the PSSF values with an

error of less than 0.05 at 40 cm2 and less than 0.01 at 4

cm2 with an average time of under half that of EnergyPlus.

We see a similar pattern for Case #9, the urban model,

where over 99.9% of the errors are less that 0.01 at 40cm2

resolution, and well over twice the speed compared to the

EnergyPlus simulation. Finally, Case #7 shows that our

pixel counting implementation can handle a large number

of shading surfaces without stability issues or an

astronomical increase in run time. There is also an

interesting pattern in the timing of a model, where for

relatively coarse resolutions, a change in the resolution

have little impact on the timing, whereas it has a huge

impact at higher resolutions. This is because there is a

certain overhead with render calls and transfering counts

from the GPU that is independent of the number of pixels

in the render target. This is why, for example, nearly all

of the ISO test cases have the same timings, except for

Case #4 and #6, which, due to their larger geometry size,

need significantly more pixels for the same resolution as

the other ISO cases, which leads to a longer run time. The

timings for the Case #9 are also rather interesting, as the

full model ran about twice as fast as the piecewise model.

This is because the piecewise model contains all of the

same geometry as the full model, but forces it to be

processed one building at a time. On the other hand, the

full model batches all the geometry together into one large

render, which allows for a faster runtime overall.

The results also show that errors in the pixel counting

method are centered around 0. This is extremely

important, as it means that our implementaion predicts the

same total amount of radiation will enter the windows as

EnergyPlus’s polygon clipping algorithm. Additionally,

the tests consistantly show that increasing resolution does

decrease the error, allowing a specific accuracty goal to

be met. However, the tests also show that the accuracy is

not just dependent on resolution, but also of the geometry

being simulated. For example, the 0.01 error cutoff could

be reached by the 40cm2 resolution for the urban model,

but required a resolution of 4cm2 for Cases #1-#6 and a

resolution of less than 0.1cm2 for Case #7. In general, a

finer resolution is needed to capture finer details in the

geometry.

In modern architectural design culture, building

performance simulations remain underutilized as

“generative” design tools. Energy models tend to be

especially underrepresented in the fast-paced early design

phase. The importance of implementing evaluative tools

during the early design phase, however, is self-evident

given that decisions made at this point such as building

proportions and their spatial interrelationship with the

context, largely “make or break” the intrinsic energetic

performance of a building. One reason for the lack of

acceptance may be traced back to their slowness. The

results presented in the previous section have shown that

it is possible to significantly accelerate energy simulations

PREPRINT Proceedings of the 15th IBPSA Conference

San Francisco, CA, USA, Aug. 7-9, 2017

438

and therefore may facilitate a wider adoption of energy

modeling software in the earliest stages of architectural

and urban design. Another, caveat of current energy

modeling tools in the design environment is that they are

often regarded as less sensitive to geometric changes. This

perception is certainly related to the current geometric

limitations that are imposed by the polygon clipping tools.

The proposed pixel counting method in contrast can deal

with complex high-polygon-count geometry, such as the

cylinders in Case #7, in a more efficient manner and

therefore allows designers to test complex geometries

with ease.

Another benefit that is energy and daylighting studies can

be conducted more consistently. While daylight models

often directly utilize the architectural CAD geometry for

the analysis, energy model geometry must be abstracted.

While this is still true for geometry that is partaking in

heat transfer processes, the proposed method would allow

modelers to keep architectural CAD geometry for shading

devices and context. This significantly facilitates the

model generation for complex facade shading geometry

but also in urban design applications.

Urban building energy modeling [UBEM] is a nascent

field of research. Modelers that are interested in energy

implications of cities with hundreds or thousands of

building often rely on simplified models ranging from

statistical methods to modeling archetypical buildings as

dynamic BEMs and then extrapolating the results.

Speed and robustness achieve by implementing pixel-

counting allows modelers to run multi zone building

energy models within a feasible time. Simulations for the

previously mention urban example included 121

buildings and completed within 1218 seconds, whereas

EnergyPlus could not handle the model without extreme

preprocessing.

Conclusion

In this paper, we proposed a new pixel counting-based

algorithm with transparency support and performed

accuracy validations and speed tests on an

implementation of the algorithm in C# using the

widespread OpenGL 2.0 technology. The results of the

tests show that pixel counting is a viable replacement for

polygon clipping: our implementation can calculate PSSF

values with error less than 0.01 in less than half the time

of EnergyPlus’s polygon clipping implementation.

Additionally, our implementation can handle very high

detail shading devices composed of millions of polygons,

as well as large urban models with relative ease. This is

compared to EnergyPlus, which cannot at all handle such

shading devices, and requires heavy preprocessing and

simplification to be able to handle an urban scene. Finally,

our algorithm, unlike Jones et al.’s, supports transparency,

and thus has all of the features of EnergyPlus’s current

polygon clipping shading algorithm, and thus can

function as a drop-in replacement. As such, we highly

recommend that our implementation be incorperated into

the main EnergyPlus codebase, and that other systems

needing a direct radiation shading algorithm prefer a pixel

counting-based approach rather than a polygon clipping-

based approach.

Acknowledgement

The authors would like to thank the Cornell University

David R. Atkinson Center for a Sustainable Future for

funding this research as well as NVIDIA for supporting

the project with a hardware grant.

References

Crawley, Drury B, Jon W Hand, Michaël Kummert, and

Brent T Griffith. 2008. “Contrasting the

Capabilities of Building Energy Performance

Simulation Programs.” Building and

Environment 43 (4): 661–673.

Crawley, Drury B, Linda K Lawrie, Frederick C

Winkelmann, Walter F Buhl, Y Joe Huang,

Curtis O Pedersen, Richard K Strand, et al.

2001. “EnergyPlus: Creating a New-Generation

Building Energy Simulation Program.” Energy

and Buildings 33 (4): 319–331.

EnergyPlus Development Team. 2016. “EnergyPlus

Engineering Reference: The Reference to

EnergyPlus Calculations.” Lawrence Berkeley

National Laboratory.

Hiller, Marion D.E., William A. Beckman, and John W.

Mitchell. 1996. “TRNSHD — a Program for

Shading and Insolation Calculations.”

University of Wisconsin-Madison.

“ISO 13791:2012-03 Thermal Performance of Buildings

- Calculation of Internal Temperatures of a

Room in Summer without Mechanical Cooling

- General Criteria and Validation Procedures.”

2012. Beuth.

Jones, Nathaniel L., Donald P. Greenberg, and Kevin B.

Pratt. 2012. “Fast Computer Graphics

Techniques for Calculating Direct Solar

Radiation on Complex Building Surfaces.”

Journal of Building Performance Simulation 5

(5): 300–312.

doi:10.1080/19401493.2011.582154.

Klein, Sanford A. 1979. TRNSYS, a Transient System

Simulation Program. Solar Energy Laborataory,

University of Wisconsin–Madison.

McCluney, R. 1990. “Awning Shading Algorithm

Update.” ASHRAE Transactions 96 (1): 34–38.

Olgyay, Aladar, Victor Olgyay, and others. 1976. Solar

Control & Shading Devices. Princeton

University Press.

Yezioro, Abraham, and Edna Shaviv. 1994. “Shading: A

Design Tool for Analyzing Mutual Shading

between Buildings.” Solar Energy 52 (1): 27–

37.