Revision history [back]

This is awesome and ambitious and not without its problems and challenges.(!)

First of all, the dctimestep command in your example suggests repurposing the three phase stuff that's in the OpenStudio Radiance measure; this method will produce images that are far too coarse in resolution to be valid for glare evaluation (last I checked, dctimestep still only works with the Tregenza sky discretization (145 + 1)). You will also need a command to generate the daylight coefficients, and they need to be luminance coefficients (opposed to illuminance coefficients as we generate for the illuminance maps).

Also be aware that blindly globbing all the views could result in a ton of images to generate, and this takes enormous amounts of time and requires a lot of disk space to store, and memory to merge. We ran into enough problems just trying to manage all the matrices for all the illuminance maps, and these are usually on the order of 100-2000 rows, and a single 200px square image is 40K rows.

A better approach might be to generate regular (single point-in-time) images, with a continuous sky model and an actual source for the sun. Which brings up the question of where are these views you're rendering? Are they the viewpoints on the window that are automatically placed by the Radiance forward translator, or are they user-defined "glare sensor" points? If the latter, your rendering parameters will need to be a tad higher (read: take longer). The views should be defined as angular fisheye views as well if your intent is to pass the renderings to evalglare.

There really are a lot of things to consider before rendering a bunch of images. I recommend reading Jan Wienold's work on this, starting with this paper, and considering his proposed "Enhanced Simplified DGP" methodology, which uses the vertical eye illuminance we already calculate with OpenStudio but augments this information with a simplified image that could be generated relatively easily.