Defining a light source in Honeybee[+] for image-based daylight coefficient simulations


I was reading this tutorial, in section 3.2, to calculate the contribution of the ground material to the lighting in the scene, Axel assigned a light source to the ground material by using “-m”. I need to assess the contribution of different patches of a highly reflective tower facade to the lighting in a scene inside a room across the tower. After reading Axel’s tutorial I’m kind of convinced that this can be accomplished by splitting the tower facade into smaller surfaces(patches) then assigning them as light sources. Radiance experts please correct me if I’m wrong.
Is it possible to assign a light source to a surface in Honeybee [+]? Currently, all light sources in HB[+] are sky matrices, unless I’m missing something.

Update: if this is not possible in HB[+], can I get the desired results by adding the patch’s material name preceded by -m, for example, patch1’s material is called ref_glass_1, so I can simply add **"-m ref_glass_1"** to the end of the rcontrib line, am I right?


Hi @RaniaLabib,

This functionality is currently not supported through GUI in HB[+].

We do, however, use rcontrib in our workflows extensively. For all the pure Monte-Carlo calculations in the DC and multi-phase methods, instead of invoking rcontrib directly, we use rfluxmtx to do all the modifier-related work. Rfluxmtx in turn uses a function file to assign sky patches as modifier while invoking rcontrib The function file is either, or (you can figure the exact one out by doing a getinfo on one of the files created through rfluxmtx).
For direct sun calculations in the DC method and Five-Phase Method, we use rcontrib directly through the -M option (where one defines a list of modifiers). The modifiers in this case are the individual sun positions derived through the EPW(file). So, you could add the additional surfaces here and perform the rcontrib calculation. However, since your facade patches are secondary sources (not glow or light primitives), I am not sure if this entire exercise would be accurate or not. The traditional way to handle secondary sources in Radiance has been through mkillum.


@sarith Thank you for the thorough explanation! I need to dig deeper into Radiance, so in the next few days, I will be experimenting with mkillum, rcontrib, and refluxmtx.


@RaniaLabib This presentation by Jack de Valpine is more than a decade old, but you might find it useful (there as some common themes in terms of the end goal):


@sarith this is very similar to what I want to accomplish, the problem is lack of details on the execution process. I have posted here and I got some help from Greg Ward on using rcontrib. I’ll see if I can get this to work, I don’t mind using the command line on Windows or Linux as long as the geometry is exported from Honeybee.


I don’t think that I am mature enough (in Radiance years) to grasp Greg’s reply in a single reading. Just out of curiosity, is this research or an actual project?


It’s a research. I’m still trying to grasp Greg’s answer as well. I will start by following Axel’s tutorial and see if I can advance to creating a bin and get the results as a materix.


Hi @RaniaLabib, I just checked the updates on the unmet hours discussion. Are you doing point-in-time simulations with rpict instead?


@sarith, I guess so. I think I hit a roadblock on rcontrib. Although, I don’t think it’s an ideal solution, but I’m very tight on time. I usually don’t give up easily but time is very precious to finish my dissertation on time!


@sarith , Typo **** I guess so****


@RaniaLabib I had done something similar for my dissertation research but I was content doing a proof-of-concept and comparative validation with rpict (See Chapter 4). I was more interested in studying if the coefficient based-approach was workable at all and if there was any benefit to using highly discretized skies. Its this workflow that we’ve implemented in Honeybee daylight coefficient-based simulations.

The issue with assigning additional sources in HB[+] right now is that we are using rcontrib and rfluxmtx to strictly create coefficients to sky-patches (1+144xNxN, where N can be 1,2,3,4 etc) and sun positions (whose number is based on the EPW data). Since the coefficients are for these sources, the sky and sun vectors we create for matrix-multiplication with dctimestep correspond to the same number of patches. The challenge with additional sources is that then the whole matrix multiplication part of it wont work anymore (as we’ll have more coefficients than luminous patches).

I think getting a general solution to work with that kind of scenario will require somewhat of a deep-dive into rcontrib. This is a good research question and worth pondering in the long term. If I get anywhere towards a general implementation of a solution for this, I will keep you in the loop.


@sarith, It is indeed a very good research question.

I just read through chapter 4. Very interesting dissertation, great job! I tried assessing glare in the image of the combined images from the image-based coefficient simulations, I can get a DGP value, but I can’t get colored areas that show glare sources in the check file that I attempted to create using evalglare as follows:

evalglare -u 255 0 255 -vth -vv 180 -vh 180 -c Filename_ckeckfile.HDR Filename.HDR

And as I mentioned in Unmet Hours, in order to determine the offending glass panels, I have to have a color overlay on top of the images for further image analysis in Matlab.

This issue steered me away from the DC method, but after reading your dissertation, it looks like a color overlay wasn’t a problem for you, so perhaps I’m missing something.


@RaniaLabib That’s odd. Can you share the view file and the resultant HDR file from the DC simulations here? (or you can inbox it to me).