Hello friends:
I have a question about the newest version of Honeybee-Radiance in terms of providing 3-channel values. I’m using Ladybug & Honeybee, and Lark (Mehlika Inanici - Research) that simulates circadian lighting quantities and requires three channels of point-in-time simulation results from R, G, and B channels, respectively (the component of “Lark 9-channel Circadian Luminance v2”). Given that the Lark tutorials were made in 2020, Version 0.0.66 of Ladybug & Honeybee for Rhino 6 was used. However, recently the newest version is 1.6, which provides the “HB Point-in-Time Grid-Based” component for simulating illuminance values. This component doesn’t provide three channels of values but only the final illuminance values. I tried to install Rhino 6 & Version 0.0.66 for simulation, but GH keeps giving me the error of “different versions of the Grasshopper SDK, Local SDK = 6.24.20079.23341 Referenced SDK = 7.0.20314.300”, which I fail to figure out a solution. I also tried to directly use the component of Version 0.0.66 in Version 1.5 (and 1.6), but the file neither works nor reports errors with the only error of “you need to let the Honeybee fly first”.
I’m wondering if it’s possible to use version 1.6 to directly obtain 3-channel values. Can anyone help me with this question?
Thank you very much in advance.
The 3 RGB channels are something that is built into Radiance and so there are actually values for them in the Radiance simulation but we just average them together at the end to give you the overall illuminance.
Granted, both for Legacy and LBT, the difference in the RGB values is meaningless because the sky is rendered in greyscale and all materials of the honeybee objects are grey by default. So, for the RGB values to be meaningful in either Legacy or LBT, you will need to first generate a colored sky. We have an open issue to support colored skies:
It seems like it’s generally a pretty quick thing for us to add to LBT 1.6 thanks to the sample @sarith posted here:
But, in addition to that, you would have to assign modifiers with real RGB values to all of your Honeybee geometries.
After that, you will be able to see the colors of everything coming through in the simulations that you run with HB Point-in-Time View Based recipe. And the values that you get in the HDR image will be suitable for circadian studies. So I would start with view-based studies and, if what you get in the images is making sense, we can probably help you get the RGB values from the grid-based studies.
If you have a model with colored modifiers ready to go, I’ll see if I can add the colored skies later today.
The updated “Climate Based Sky” component with the new _colored option should be available with the LB Versioner shortly. After that, you should be able to set up Point-In-Time simulations with meaningful RGB values. If you get to that point of setting everything up correctly, @ZheKong , I can point you towards where you can find the RGB results from the grid-based recipe.
Hi @chris,
Tested this new option. Thanks.
It works for most cases but there are months/hours that the rendered sky turns into the “traditional” grey, like so:
Basically, if the conditions that you are inputting do not align with the expectations for a clear or overcast sky, the model will default back to the usual greyscale. So, yes it’s the result of your EPW and the fact that there really isn’t a great sky model in Radiance to represent the partly cloudy conditions in that part of your EPW model.
If you stick to using the HB Wea from Clear Sky component in order to make a Wea with completely sunny skies, you can be effectively guaranteed to get skies that are all colored.
Hello Chris:
Thank you very much for your quick responses. Apologize for not clearly describing my question. Here is my logic of simulation, along with the files for examination.
I measured the spectral power density of self-luminous signboards and planned to simulate both circadian luminance and illuminance by using both Honeybee-Radiance and Lark. I followed the same method as you suggested, to simulate view-based first and move to grid-based later. The former works well, and the latter gives me some difficulties.
Please download all the files through the dropbox link below: https://www.dropbox.com/scl/fo/ddr9kdixr06s0wd3qwswg/h?rlkey=87xdofp2o3c7b1604uz0n0w4a&dl=0
This folder contains two folders: A view-based one and a Grid-based one. The former contains a Rhino model, a GH file, SPD files (txt files) for Lark simulation, as well as the simulated luminance maps of R, G, and B channels and final results, respectively. Based on these files, the nine-channel simulation method works for 1.5/1.6 version of LB & HB.
The latter contains a Rhino model, a GH file, and SPD files for grid-based simulation, which is the focus of my question. Currently, only illuminance results of each channel (RGB) are generated, which failed to transfer to Lark for calculating circadian illuminance value. Could you let me know how to solve this issue?
Thank you very much.
The Grid-Based recipe is really not set up to record RGB values and the “right” way to add something like that is to create a separate recipe that keeps the RGB values (and probably does some circadian post-processing on them). If you want to hack it quickly for now just to get it to work, you can comment out these lines of code in the honeybee-radiance package:
That should remove the post-processing that is currently converting the RGB values into a single illuminance value.
Hello Chris:
Thank you very much for your answer.
I commented out these lines in the raytrace.py file under the path (C:\Program Files\ladybug_tools\python\Lib\site-packages\honeybee_radiance\cli). However, the simulation took three days without completion, which is way longer than it used to take (around 10 minutes). The terminal responses are uploaded. May I ask for further suggestions concerning this question?
It looks like you commented out the lines in a way that all of the matrices are being dumped into the stdout instead of being written to text files. Did you only comment out the e option or did you comment out the whole rcalc function?
Hello Chris:
I only commented out lines 202 to 205, as you suggested last time. I’m attaching a screenprint in the attachment since it is not allowed to upload the revised raytrace.py file.
When you run the recipe in Grasshopper it will probably turn the component red as an error. This is because it cannot read the results anymore, but the recipe should run fine, and you can find the results in the results folder of the project.
