HB IES Component - setting variable multipliers per luminaire _ptsList

Hi, have been using HB's IES_Luminaire component to create typical 'luminaire zones' from a point list. I have had success using a single _candelaMultiplier for multiple points; however, when I feed in a list of multiplier values that matches the number of points, I am returning a data tree that duplicates each value by the number of points.

In the posted example, I am using four points. Accordingly, the results consist of 4 branches where each branch contains all four luminaires associated with the first value of the multiplier list. The second branch duplicates the luminaires and associates them with the second value (and so on)… I have tried grafting the input list to return 4 luminaire zones and this doesn’t help. Is it possible to supply a list of multipliers in this way?

Please let me know how I can approach this problem. Thank you very much.

Image with single _candelaMultiplier showing the correct multiplier values per luminaire


Image with multiplier list showing the incorrect duplicated values in datatree


IES_candala-values.gh (77.6 KB)

The images are not seeming to work in the above post, so I have attached them here.

Image A from previous above post

Image B from previous above post

Hi,@ebroberg Maybe the structure of data is not matched. You try to inactive the flattern luminaire zone.

@minggangyin - thank you for the reply. I have tried your suggestion to no avail. Also, I have attempted grafting the ‘input pts’ to return multiple luminaire zones; however, this causes the same duplicate data issue.

The component seems to be written to handle data structures, so I assume I’m missing something. Thank you again

Hi,@ebroberg You grasshopper definition is right. It generated 4 lump as followed

Here is ies file.
v0_90h0_90.ies (2.1 KB)

Using the component this way (i.e. assigning individual candela multipliers to luminaires) is something that I did not foresee happening back in 2015 when we created these.

In case @minggangyin’s solution is not working, I think one other way could be to create four different IES luminaires, thus generating four different rad files, and then link them to the daylighting simulation component.


@minggangyin - thank you again for looking into this. The imageBasedSimulation you have posted seems to show variation in multipliers per each luminaire instance; however, I am still getting duplicate multiplier values in the data tree. What seems to be happening is that ‘candelaMultiplier[i]’ is assigned to all points, placed on a branch and then repeated.

@sarith - Thank you for your response as well. The suggestion you have provided works; however, it becomes difficult to track if I have 30 or so LEDs that I need to individually manipulate.

Similarly, I assume that if I want to adjust the RGB values of a similar number of LEDs, I would need to follow a similar workflow with the Custom Lamp component?

Once more, I appreciate your time.

Hi @ebroberg, so I thought I could hack through the code (over an evening cup of tea) to do what you are intending to do by making changes to the IES luminaire zone and IES luminaire components.

I made some progress till I ran into a fundamental issue with how the component is set up right now (and also how Radiance expects us to specify multiple luminaires of the same type): Each IES luminaire on the gh canvas is a unique entity that parallels a single system call to the Radiance ies2rad. This is followed up by a number of calls to the Radiance xform such that this number is equal to the number of points in the luminaire zone. The candela multiplier is assigned in the call to ies2rad. The calls to xform only contains translation and rotation related data as xform is only used to move things around. So if you are to assign multiple candela values, there is no other way to do it other than create multiple IES luminaire components on the canvas.

I am sorry that this wasn’t really a solution to your issue, however, I thought should add this to the discussion in case someone runs into something similar in the future.
IES_candala-values_Hack.gh (530.6 KB)


PS: I have uploaded the hackfile with the half-finished code for future reference as well.

@sarith - I apologize for the late reply.

I appreciate you taking a deeper dive into and attempting to implement this workflow. The fact that ies2rad / Radiance xform are the culprits is interesting. As Radiance treats each ies2rad as a single entity, then it seems that nothing can be done other than to hope this workflow is supported by the Radiance developers in the future.

Thank you again for helping out and posting your work. Once more, I appreciate the help as well as the development of the components in the first place!