Issues while generating East or West shading devices

Hello guys,

While doing a project for shade benefit analysis tackling specific indicators related to daylight quality I found out some issues.

I have been trying to make some shading devices with the LB shading device creator,
when I turn the boolean toggle into “false” in order to generate “vertical” shading devices, it usually gives illogical results, when i take into account the Sun Vector input, when is use the input from 0<3, I can get some results but they are not vector based.

Is there a problem with my set up?

I will attach the definition. (136 KB)


I apologize for such a late reply. The shade generator component can start to freak out when you give it sun vectors that are close to being perpendicular to the window surface (since these sun vectors cannot be blocked with shade surfaces that are perpendicular to the window). I would suggest one of the following:

  1. Do not using the sun vector input if you are going to use very low sun angles (just use the depth)

  2. Angle your shades so that it is possible for them to block the low sun.

  3. Use the shade benefit evaluator component to visualize the sun you want to block instead of the shade generator component.

Mostapha might do a revision of the sun vector methods of this component with the new version of Ladybug since it is related to geometric view factor calculations that I know he has been planning to rewrite for a while. I am sorry that I can’t offer a better solution for the time being.



Thanks a lot I will take that into consideration and move on, angling the shades might work and perhaps try different sorts of iterations of design I can come up with.


I’m not sure if we can call this an issue. The shading generator tries to generate the geometry that covers the glass from the sun vector. If the sun vector is almost perpendicular to the surface then the shading will be a close to infinite surface.


To clarify, I have put a check into the component that identifies any vectors that are perfectly perpendicular to the window, discounts them, and gives a warning. Luis is getting one of these warnings in his file and so, to some extent, things are working as we like.

However, it is also possible to put in vectors that are “close” to being perpendicular, which are tough to identify but can nevertheless make the (sometimes buggy) Rhinocommon intersection calculations go crazy. I don’t know what exactly what counts as a “close” enough vector and I should investigate this in the future when I have time. In the meantime, I worry about limiting people’s freedom to input different vectors if I try to put in something to take out “close enough” vectors without understanding exactly what they are. So user self-policing their inputs seems to be the best policy until someone gets time to investigate this.