Electric Lighting for Honeybee Release

pre-release

#21

Forgot the attachment in the previous reply…

MonaTrialv1.gh (1.41 MB)


#22

Sarith ,

Finally I had a result :slight_smile: . I guess the problem was the way of plugging the IES file, So if you don’t mind tell me how to have IES file as written one .

Thank you so much

Mona


#23

Hi Mona,

That is a “secret” (or rather poorly documented) feature in the IES luminaire component. You can copy and paste the contents of a IES file directly into a text box and make it work (instead of assigning the path) as I have done in my file. Did that answer your question?

By the way, I found a tiny bug in the code while working on your file. I have requested Chris to update. It might be that you were getting errors due to that bug. https://github.com/mostaphaRoudsari/Honeybee/issues/540#issuecommen…


#24

Hi Sarith ,

Yes that answered my question , thank you for telling me the secret :slight_smile:

I have no idea about coding but I really appreciate your efforts in solving problems here . I’m happy being a part of this platform and knowing awesome people like you :slight_smile:

Many thanks,Sarith .

Wish you all the best ,

Mona


#25

Hello Sarith,

It’s nearly one year after your original post and I have been trying out Honeybee’s electric lighting analysis. I agree with what has been said by one of the posters that Honeybee may be a “game changer” regarding lighting simulations and analysis. To harness the power of Grasshopper, the flexibility of Rhino in a lighting specific application is, I believe, already the future.

Because of the above I am a big proponent of Honeybee for the professional environment, but I feel that there are still a few shortcomings… from what I have tried.

  1. It should be “photometrically” more comprehensive, not just for illuminance, luminance and energy (W.h). Other quantities are of great importance, namely intensity and flux.

  2. Producing documentation is a big advantage (if not the main advantage) of dedicated packages such as Dialux or AGI32, it would be nice to see it as a strong feature in Honeybee as well.

  3. Support for Eulumdat would be a nice feature.

  4. There is a performance issue with multiple sources as you mentioned. I have tried a “simple” analysis with 120 sources and it takes, indeed, a substantial amount of time to produce the result. Don’t know where the bottleneck is, perhaps not Honeybee’s to blame, but it is a hindrance in using the software for complex simulations.

  5. Material/surface design would benefit from more options.

Finally, do you have a roadmap of sorts and what can the users expect from Honeybee electic lighting in 2017?

Have a great year!! All the best.


#26

Hi Aristo,

First, to reply to your numbered comments:

  1. Flux in lumens, as reported within the IES file, is currently displayed through the luminaireDetails output. I wasn’t quite sure if candela values are of any use from a display perspective as some IES files tend to have upwards of a 1000 numbers. That is why the candela values are visualized in the Rhino viewport.

  2. Did you check out the (relatively) new Honeybee_IES Project component? It does produce a Bill of Quantity and also allows an export to Excel. I have explained this here: http://www.grasshopper3d.com/xn/detail/2985220:Comment:1474434

  3. Eulumdat to IES is an easy fix. I wasn’t aware that anybody had tested this using Eulumdat files. I will add this feature when I update the code next time.

  4. Can you describe this simulation? The time taken by the simulation itself should not be that long because Radiance ( the calculation engine) has optimization algorithms to tackle multiple sources. My comment about multiple sources had more to do with Rhino than HB itself.

  5. What do you mean by material design ? As in textures for surfaces?

Now, with regards to future work, we don’t have a road-map of sorts at present as personally I am not quite sure about what might be useful to people who work exclusively with electric lighting. Most of the (vocal) users of Honeybee tend to be interested in Daylighting and that is where our development efforts have centered over the past year. You can read more about it here and here.

If there is some sort of consensus-based opinion from lighting designers on what would be useful we will look into adding new features.


#27

Hi again, Sarith

Thanks for your reply. Clearing up some points:

  1. What do you mean by “That is why the candela values are visualized in the Rhino viewport”? Are you refering to the luminance analysis (cd/m^2), or am I missing something? I think it would be very useful to have a mapping of light intensity over the field of view of the used camera, and possibly and option to overlay it on the luminance mapping. It would in a very visual way provide information about contrast and glare.

  2. It’s just a shoebox type simulation. 11x11 luminaires pointing down to simple materials. The default elapsed time was 3m40s. I have found the _RadParameters component meanwhile, and got it down to 0m30s. I have noticed that the simulation doesn’t tax multiple cpu threads completely, most of the time cpu is at 25% during execution.

  3. Is it possible to map different degrees of translucency, diffuse color, absorptance, reflectance, etc…, by means of a bitmap image, expression, or other?

  4. There is a feature that I consider absolutely necessary (and I haven’t found it yet), which is the emitting surface feature, with the ability to stipulate homogeneous intensity with luminance values (in cd/m^2) or flux; and by mapped distribution of intensities or luminances (in cd or cd/m^2).

By emitting surface I don’t mean just a flat rectangular plane, such as an area light. It would be absolutely amazing! to perform photometric analysis on irregular and convoluted shapes and the light falling on neighbouring surfaces. 3DS Max with MentalRay provides similar functionality, but without the power of GH + HB.

Otherwise, the more I use HB, the more I like it! Have a great year!


#28

Hi Aristo,

My replies are inline.

  1. What do you mean by “That is why the candela values are visualized in the Rhino viewport”? Are you refering to the luminance analysis (cd/m^2), or am I missing something? I think it would be very useful to have a mapping of light intensity over the field of view of the used camera, and possibly and option to overlay it on the luminance mapping. It would in a very visual way provide information about contrast and glare.

Doesn’t the falsecolor option already do that for luminance mappings? If not can you post an image/screenshot of such a mapping from Dialux/AGI32 or any other software.

  1. It’s just a shoebox type simulation. 11x11 luminaires pointing down to simple materials. The default elapsed time was 3m40s. I have found the _RadParameters component meanwhile, and got it down to 0m30s. I have noticed that the simulation doesn’t tax multiple cpu threads completely, most of the time cpu is at 25% during execution.

The under-utlization of CPUs is a known issue with Radiance (the calculation engine) on Windows based systems. Unfortunately there isn’t much that can be done about it at the moment.

  1. Is it possible to map different degrees of translucency, diffuse color, absorptance, reflectance, etc…, by means of a bitmap image, expression, or other?

  2. There is a feature that I consider absolutely necessary (and I haven’t found it yet), which is the emitting surface feature, with the ability to stipulate homogeneous intensity with luminance values (in cd/m^2) or flux; and by mapped distribution of intensities or luminances (in cd or cd/m^2).

By emitting surface I don’t mean just a flat rectangular plane, such as an area light. It would be absolutely amazing! to perform photometric analysis on irregular and convoluted shapes and the light falling on neighbouring surfaces. 3DS Max with MentalRay provides similar functionality, but without the power of GH + HB.

In the image below, the HB logo is assigned as a texture to a glass which then creates a pattern of that on the wall when daylight falls on it.

ln the image below the light from the Batman logo illumninates the scene.

The images above were Rendered with Radiance. While these things are possible with Radiance, and therefore HB, the reason why they aren’t incorporated into the code is that these effects are not “physically based” and are not rooted in reality. Radiance is arguably the most intensively tested and validated lighting simulation software in the world. However, once we start applying such “magic” to it, the results from it are no longer reliable and therefore no different from other photorealistic engines such as V-ray, Mental-Ray etc.


#29

Hi Sarith,

I uploaded your script from http://hydrashare.github.io/hydra/viewer?owner=sariths&fork=hyd…

However, when I updated the file with UpdateHoneybee, it shows “Solution exception:Local variable ‘tiltInfo’ referenced before assignment” at the Honeybee IES Luminaire command. Did I do something wrong ? Is it about updated Honeybee version?

Thanks in advance.

Api

IES_Electric_Lighting_Demo_Setup_01.gh (712 KB)


#30

Hi Api,

I think the TILT issue most likely has to do with the ies file than a bug in the source code. Can you share that file as well?

Anyways, I have just uploaded a new example, that is slightly more complex and “architectural” to Hydra. This example works with the latest components. You might want to test your IES file with that example.

You can download the example here.


#31

Is it possible to set number of luminaires (which can be connected to a slider) to be later optimized in MOGA?