The VI-Suite: a set of environmental analysis tools with geospatial data applications

Blender

Blender¹ (Blender Foundation) is a free and open-source 3D application that aims to be a ‘Swiss-army knife’ for digital content creation. It includes a mesh-based 3D modeller, advanced materials and texture specification, animation system, a physically based renderer and a deeply integrated Python² Application Programming Interface (API) amongst other features. Some of these features have made Blender an increasingly popular host application for a range of scientific visualisation and analysis tools [2–5] including GIS data processing³ and other GIS related visualisation applications [6–8]. These key features include:

Mesh based modelling As opposed to a surface (e.g. Rhino) or solid (e.g. Solidworks) based modeller, geometry in Blender is primarily stored as a mesh, i.e. geometry is composed of vertices, edges and faces. This allows data to be associated with, and visualised at, specific geometric points, and the distribution of those points is easily manipulated by the user. It also means Blender can natively import and export a number of common mesh based geometry formats such as OBJ and 3DS with no loss of geometric detail.

Python API Python is an open-source, high-level computing language used for Blender’s API. This Python API is deeply integrated allowing, for example, specification of data and control over mesh elements, manipulation of the Blender interface and the drawing of custom OpenGL graphical elements over the interface itself. With the Python API it is therefore possible to create custom user interfaces to control the creation and visualisation of mesh based data.

Animation System Blender’s frame based animation system can be used to visualise variant data sets and is also used by the VI-Suite to specify variant simulation contexts that enable parametric as well as static analyses.

In addition, the Blender interface is very flexible and customisable for different usage cases. This, coupled with the Python API, allows plugin (called addons in Blender) developers to create embedded custom user interface and display elements.

VI-Suite history

The features mentioned above made Blender an early choice as a host application to provide geometry and materiality creation and export for the Radiance lighting simulation suite [9]. Early examples include Brad⁴ and Radex.

Radiance is a set of free, multi-platform and open-source tools for the visualisation and calculation of artificial and natural lighting and radiation metrics. Radiance comes with no native user interface and consists mainly of a number of executable files, typically run from the command line. This has made the use of pure Radiance somewhat problematic for novice users and students [10]. Radiance can however accept mesh based geometry descriptions and can convert OBJ files to native Radiance geometry. The mesh based geometry format used by Blender, coupled with the ability to create custom user interfaces with the Python API, made Blender an appropriate choice to act as a Radiance frontend. In these early examples Blender acted primarily as a pre-processor i.e. a geometry/material creator and exporter that could initiate the Radiance simulation and visualise the results using Radiance’s native rendering tools.

The first component of the VI-Suite, the Lighting Visualiser (LiVi), was inspired by these early examples to embed Radiance functionality within Blender. LiVi began in 2009 as a standalone addon for Blender that would convert Blender geometry and materiality to a valid Radiance format and initiate the Radiance simulation via additions to the Blender user interface. A key difference to previous Blender/Radiance integrations was that LiVi could then post-process or import numerical results generated by Radiance back into Blender for visualisation. This was achieved by specifying Blender mesh geometry as sensing surfaces and then colouring the faces of that geometry with the Python API according to the results generated. Figure 1 shows an early LiVi simulation of instantaneous solar irradiation within a city scene. The legend is drawn over Blender’s 3D view by LiVi via the Python API.

The advantage of including post-processing within the scope of the addon was that results could be navigated and visualised in-situ very quickly to encourage fast, performance based architectural design iteration.

In 2013 development began on the Energy Visualiser (EnVi) a standalone Blender addon that would act a a pre/post-processor for EnergyPlus; a free and open source application for building lighting, energy and ventilation performance analysis [11]. EnergyPlus also comes with no native geometry creation or specification interface and uses text based descriptions of mesh geometry to define building form, again making Blender a viable frontend application.

Whilst EnVi was still at prototype stage Blender introduced Python scriptable nodes. Nodes in Blender were traditionally used to apply a sequence of filters to an image but version 2.67 introduced the ability to create custom nodes via the Python API.

A nodal interface can provide a more flexible and intuitive user experience by allowing the user to construct their own task specific interface, especially if the activity undertaken can be broken down into discrete stages. These scriptable nodes therefore presented the opportunity to combine LiVi with EnVi, along with a number of other contextual analysis tools, into one node based interface called the VI-Suite. A sabbatical award from the University of Brighton in 2014 enabled the release of version 0.1, and at the time of writing version 0.4.12 of the VI-Suite is publicly available. Figure 2 shows a typical current Blender and VI-Suite window configuration showing the 3D view, where geometry is edited; the node editor, where VI-Suite simulations are constructed; the VI-Suite display panel, where visualisations are controlled; the VI-Suite material panel, where material characteristics are defined; tabular and graph OpenGL overlay elements, where result data can be visualised. Figure 3 shows a typical node set-up within Blender’s node editor for a LiVi lighting simulation with location, geometry, context and simulation nodes representing location specification, geometry export, sky export and simulation stages.

Nodes provide the majority of the VI-Suite UI, encompass much of its functionality and are, in terms of Python code, objects i.e. instances of a class. These node objects have properties (integer, string, menus etc) associated with them which can be exposed within the node using Blender’s standard interface elements. The nodes also contain functions, or methods, to draw and update the node. The nodes can also display buttons which, when pressed, run operators or Blender specific functions. These operators in turn run general functions that, for example, initiate a Radiance simulation or embed simulation results within the Blender mesh for visualisation. A more detailed explanation of the input elements of specific nodes is given in the next section.

Using Python objects in the form of Blender nodes has led to a modular, object-orientated code base that can be relatively easily extended to, for example, import geospatial file formats. Users have already contributed nodes for window shading analysis in EnVi and further contributions are welcome.

As the close integration of the VI-Suite with Blender offers extensive possibilities for advanced results visualisation, recent releases of the VI-Suite have concentrated on this aspect. Using the Python API to draw OpenGL graphics over the main Blender window, the VI-Suite can now display per-point numerics, scalable legends, scatter graphs and tables etc. within Blender’s 3D view (Fig. 2). In addition, legend values, scaling and colouration can all be controlled by the user.

VI-Suite capabilities

As the VI-Suite takes the approach that Blender mesh geometry forms the basis for the specification of calculation and visualisation points, any geometry data imported into Blender can be quickly turned into a sensing surface by associating a sensing material to some or all of the faces of the mesh. Simple ground planes, 3D topographical data and even building geometry can therefore all form the basis of the calculation/visualisation points.

By using Blender mesh geometry as sensing surfaces the user also has complete control over the spatial density of the calculation points. Mesh density can be increased or decreased locally, using Blender’s advanced mesh editing tools, to achieve the desired results resolution whilst minimising calculation time. This level of calculation point control can also be valuable in geospatial applications where simulations over a wide area may be desired that would require many calculation points at high spatial resolution. Instead the user can begin with a coarse sensor mesh and refine locally where greater results resolution is required.

Although originally intended for the performance analysis of buildings and their immediate context, this ability to specify any mesh based geometric surface as a sensing surface does offer a number of possibilities for geospatial analysis and these possibilities have been augmented with the ability to directly import geospatial data. These features include:

Shadow & sky view factor mapping

Two of the types of geospatially relevant analyses that the VI-Suite can conduct are shadow and sky view factor (SVF) mapping, and both are calculated in a similar manner.

A shadow map defines the proportion of the simulation period that a point is exposed to direct sunshine assuming that the sky is clear at all times. This can be useful for agricultural or ground based solar power applications and, if building geometry is defining the sensor points, a simple analysis for Building Integrated Photovoltaic applications and building overshadowing.

A Sky View Factor (SVF) map rather simply defines the proportion of the sky hemisphere that can be seen from a point i.e. not occluded by buildings and other urban features, and is therefore not site location or time dependent [12–14]. This type of analysis is often conducted on or above the ground plane within an urban context where buildings obscure a potion of the sky, and is useful for urban sky views and street canyon enclosure assessment.

Both these analyses may require a large number of computations when conducted on large geospatial datasets, especially if the dataset is defining the sensing geometry as in Fig. 4. As in that example, if a large terrain model is defining the sensing geometry with potentially millions of calculation points, and thousands of time steps in a year, shadow map analyses may require billions of shadowing calculations. This is where the use of 3D design software, in this case Blender, can be advantageous as it provides two built-in capabilities via the Python API, often found in such software, that allows the potentially large number of calculation points generated by geospatial data to be simulated relatively quickly: Bounding Volume Hierarchy (BVH) tree creation and ray casting.

BVH trees can greatly speed up certain calculations the result of which are the positions of spatial intersections e,g. collision detection. They are a generated set of simplified, hierarchical bounding volumes encompassing the detailed mesh geometry within the scene. Intersection calculations are initially done with these simplified bounding volumes and only passed on to the detailed geometry if a bounding volume encompasses the intersection point. The use of BVH trees does not compromise the accuracy of the eventual intersection calculation. The VI-Suite automatically converts all relevant shading geometry within the scene into BVH tree representations, using an in-built Blender function, ready for ray casting.

Ray casting calculates the intersection point of a ray vector and a geometric surface representation, in this case encompassed within a bounding volume. For shadow mapping, rays are cast at each mesh sensor point from the direction of the solar position for each time step of the simulation. For sky view factor rays are cast from each patch of the subdivided sky hemisphere (Fig. 5). If the ray intersects with the BVH tree representation of the non-sensing scene geometry the point is considered to be shadowed at that simulation time step, or the sky patch obscured. The final shadow/sky view status of each geometric sensor point is then stored within the point entity itself using Blender’s custom data layers via the Python API.

The shadow mapping analysis is conducted with the ‘VI Shadow Map’ node, with a ‘VI Location’ node to provide location data in terms of latitude and longitude. The node setup for a shadow map calculation is shown in Fig. 6. The shadow study node object contains a number of properties to define the simulation parameters. These properties are:

Sky view factor is calculated with the ‘VI SVF’ node (Fig. 7) which, as no location data is required, is a stand-alone node. The node properties are similar to the shadow map node except that the time based options are not required. One new option, ‘Sky patches’, defines the subdivision of the sky hemisphere to generate the vector directions for the ray casting calculation. The sky hemisphere can be divided according to the Tregenza (145 patches), Reinhart 577 (577 patches) and Reinhart 2305 (2305 patches) schemas commonly used in daylighting analysis [15]. Figure 5 shows a graphical representation of the three subdivision schemas. The greater the sub-divisions the greater the result accuracy at the cost of increased simulation time.

Once the simulation has completed the results can be exported to CSV formatted text file or visualised within Blender. The exported CSV file contains the point locations and results for each mesh sensing object and can be used to import the results data back into geospatial or other visualisation software. Visualisation within Blender copies the sensing meshes and colours the copies according to the results stored within the sensing points. Colour scale, legend scale, per point numeric display can then be controlled with the options in ‘VI-Suite Display’ panel. Results can be rendered out to bitmap image. Figure 4 shows a Digital Terrain Map (DTM) of the south coast of the UK overlaid with an annual shadow mapping results plane consisting of 12 million sensor points at 5 m resolution. The DTM used is a 20 ×15 km dataset by Ordnance Survey of Great Britain, obtained from Edina Digimaps [16] by importing directly the Esri grid file. This rather extreme example required 105 billion shadow calculations (12 million data points x 8760 h in a year), which, by employing BVH trees and ray casting, took 14 h on a single 3.1 GHz cpu. However, as first class Blender mesh geometry is used as the sensor points approximately 1kB of available ram is required for each sensor point to run the simulation efficiently (12 GB of ram in this particular case).

Irradiance mapping

In addition to irradiance and illuminance calculations for discrete moments in time the VI-Suite can also create irradiance maps for periods of up to a year. Irradiance maps define the cumulative solar radiation power available at a point over the simulation period. The units are kWh/m ² for total radiation and luxhours for visible radiation. A kWh/m ² calculation can be useful for quantifying the solar potential of building surfaces for installing solar panels [17–19], to determine whether a surface is sufficiently insolated to invest in a photovoltaic panel and to locate the most favourable parts of a building to place one as the amount of power produced by a panel can be estimated by multiplying the kWh/m ² value by a panel’s rated efficiency. Several research papers dealing with energy demand estimations benefited from such analyses [20–22]. Such simulations may also be used in automatic property valuation considering that solar radiation influences flat prices [23]. Other applications involving the computation of the solar exposure are urban planning [24, 25], thermal comfort [26], and detecting buildings that may be subject to overheating [27].

Irradiance mapping, although producing similar results to the shadow mapping calculations detailed above, is achieved with the LiVi component of the VI-Suite and uses Radiance in the background to calculate results. Irradiance mapping, in a similar way to shadow mapping, can be conducted on terrain meshes and on building geometry imported via Esri grid file or via the import of standard mesh formats.

The node setup shown earlier in Fig. 3 is an example of an irradiance mapping pipeline. The nodes each represent a step in the conversion to Radiance format and the control of the Radiance simulation. These steps are:

Geometry conversion The Blender mesh geometry must be converted to Radiance format and this is achieved with the operator button within the LiVi Geometry node. Not only does the spatial geometry need to be exported, but as the distribution of light or radiation within a scene can be influenced by material finish, the materials associated with the Blender meshes have to be converted to valid Radiance material definitions. Radiance material definitions are defined in the VI Material tab in the Blender interface. A node boolean property allows the user to specify whether a static or parametric analysis is to be conducted. For the latter a Blender animation of the parametric changes should be set up in advance. Any geometry within the scene being used to define the sensor points are also exported at this stage and the node allows the user, via a menu property, to select whether the vertices or faces of the relevant mesh geometry are the definer of these positions.

Context conversion The LiVi Context node defines the type of lighting analysis to be conducted, and the type of sky for the simulation; the latter again being exported to a valid Radiance description. For an irradiance map the menu properties in the LiVi Context node should specify a Climate Based Daylight Modelling (CBDM) analysis type and an ‘Exposure’ metric type. This type of analysis will require an EnergyPlus formatted weather (EPW) file selected in the VI Location node to provide the hourly beam and diffuse solar radiation data for the chosen location. The simulation period can also be set here with integer properties. During context conversion a cumulative high dynamic range (HDR) image of the sky brightness (including beam and diffuse elements) for the chosen period is produced for 145 discrete Tregenza (Fig. 5) patches of the sky (Fig. 8). As this HDR image contains accurate cumulative brightness data according to the EPW file, it can be used as a source of radiance when wrapped around the simulation scene. This approach avoids having to do a calculation for each hour step and makes the calculation of cumulative irradiance for a large number of sensor points relatively quick (an irradiance map for the 12 million sensor points on the ground plane in Fig. 4 was generated in 13.5 h on a dual core cpu).

Simulation initiation The LiVi Simulation node has a menu operator to specify the accuracy of the simulation and initiates the simulation itself. In a similar manner to the shadow study analysis, the results, which are in this case cumulative illuminance (luxhours) and cumulative irradiance (kWh/m ²), are calculated for each specified sensor point and stored back within the data point. Once the simulation is completed results can once again either be exported to CSV file or visualised and rendered within Blender.

Overview

In this section we demonstrate the use of VI-Suite for environmental analyses using geospatial data. It is relevant to note that the presented workflow is entirely supported by free and open software and datasets.

Of the three geospatially relevant analyses that the VI-Suite can conduct: shadow mapping, sky view factor mapping and irradiance mapping the focus here is on solar irradiance analysis of buildings and ground shadow analysis. These two spatial analyses are among the most applicable ones in GIS because they are used in a wide range of use cases [28, 29], although they are also often used in conjunction with other analyses such as sky view factor [13, 30]. An overview of the example cases is given below.

In GIS analysing the exposure to sun may be conducted at both coarse (e.g. terrain) and detailed (e.g. building) scales [31–33], and the ability to move between different spatial resolutions with the VI-Suite are demonstrated here.

Dataset

In the analyses presented here a 3D city model is used to demonstrate a ground level shadow calculation and building level irradiance calculation.

The 3D city model is a dataset by the City of The Hague in the Netherlands⁵. The dataset is provided in the City Geography Markup Language (CityGML) [34], and it was converted [35] to the common OBJ format with level of detail (LOD) 2 that included the roof profiles and with surfaces thematically differentiated [36] i.e. wall and roof geometry is exported as separate OBJ objects. Although not used in the shadow map example below, the convenience of this mesh separation is demonstrated in the irradiance mapping example. While the conversion of CityGML to computer graphics formats such as OBJ often entails data loss (e.g. attributes are not preserved), it does not affect the spatial analyses in question since the required data (i.e. geometry and semantic differentiation of surfaces) are retained.

The city model used here consists of around 50,000 planar faces, and covers an area of approximately 1 sq km. As each Blender mesh face requires approximately 1 kB of ram, this model can be imported/simulated with the VI-Suite using approximately 50 MB of ram. Much larger city models can therefore be simulated. As a rough approximation a city model covering 100 sq km could be analysed with 5 GB of ram.

Shadow map

The shadow mapping was carried out using a ground plane as a sensing surface. Figure 9 presents the results of this shadow study in the urban environment for the whole month of June at 4 calculation steps per hour (as specified within the VI Shadow Map node) with a relatively coarse ground plane sub-division. Analyses such as these allow for a quick appraisal of the distribution of sunlight penetration into a city.

If a greater spatial result resolution is required the sensing geometry can be locally sub-divided using Blender’s mesh editing tools. This local refinement can be useful for assessing in more detail the impact of a building, or proposed building, on the sunlight penetration in specific parts of the city. Figure 10 shows local mesh and result refinement around the block of buildings in the middle of the image. At this resolution the changes in shadowing from making one of the central buildings taller, or by introducing shading elements between buildings, could be seen in detail.

Irradiance

The 3D city model was also used to provide calculation points for the simulation of irradiance levels. The first example takes advantage of the thematic differentiation provided by CityGML. The CityGML dataset was converted to OBJ with the CityGML2OBJs Python script, which preserves the semantic description of surfaces by creating multiple OBJ datasets [35]. Blender understands this differentiation thanks to which a material specifically for the roofs may be created. This material can then be designated as a sensing material within the VI-Suite interface and a coarse irradiance map calculated at roof level (Fig. 11). Maps such as these can quickly identify the regions of the city’s roof-scape that have the potential to provide a certain amount of solar electrical power to hit, for example, economic criteria.

Irradiance levels can also be calculated on refined mesh geometry on a single, or part of a single, building. Figure 12 shows annual irradiance results on the facade panels of a selected building with the corresponding legend. Other buildings are wire-framed for the results visualisation.

As well as a coloured visualisation of the results, the VI-Suite offers per-point numerical display over selected sensor mesh elements (Fig. 13). Display is confined to only those sensor elements selected within the underlying Blender mesh, which offers fine grained control over the numerical display. Figure 13 for example shows numerical display with only the mesh faces under one façade section selected. An analysis like this may be useful if, for example, it has been determined that a solar panel must receive at least 800kWh/m ² to be an economical replacement for the conventional facade cladding. In this example this would be the case for most of the facade panels in each of the top 10 rows of facade panels for the selected facade section.