Question about missing output from LB_SunPath & LB_DirectSunHours components

Dear @mostapha and @chris,

starting to migrate the workflow for the Sunlight Hours Analysis, from LBlegacy to LBT >1.0,
I noticed some missing output, which gave me a lot of info for the final result of the analysis.

In the “DirectSunHours” component, I don´t have the “AnalysisMesh” output, with which I was able to extrapolate the treshold of a certain minutage of the analyzed surface. (like the image)

Is also was exactly the “LBMeshTresholdSelector” component do.

Another 2 missing output are the “SunPositionInfo” from the SunPath component and the “SunIsVisible” from the “SunlightHoursAnalysis” component, which gave me the opportunity to read the timeline of the visible sun vector from a point of a window or a timed out between two windows from the same room.

Most likely they are outputs that were not even present in the LB+ version, but I would like to ask if is was possible to find them in another way through the new LBT components, or if they will be added in the near future.

Liam R.

direct sun cull (31.5 KB)
The first part of your question can be done with native grasshopper components.

While responding to the next part of your problem, I believe I found a bug in the workflow which I will address before I post a solution.

Dear @devang,
I will no longer be in front of the PC until tomorrow, but I believe that your solution will only work, if I analyzed only one surface, because only a single mesh comes out of the output “mesh”, even if I analyze, per example, 4 geometries. Instead with “Analysis Mesh”, I would have the meshes of every single analyzed geometry.


@devang’s solution works just fine:

THe mesh output is a single one even if the input geometry has many surfaces.
One correction for @devang’s is that the final panel results is area % and not m2.

1 Like

Hallo Abraham,
Yes, that’s right, but I need the value (p.e. Area percentage) for each Surface.
In your example, I see only one Value (83%).
I thinks this is the sum of the percentage, of all the surfaces you just simulated.

Liam R.

Just graft the input geometry:


Thanks @devang and @AbrahamYezioro ,

To address the other two questions, you can get the equivalent of the sunPositionInfo by passing the hoys of the LB Sunpath through the “LB HOY to Datetime” like so:

And the sunIsVisible output is still there. It’s just called int_mtx now (short for “intersection matrix”) and all of the data is wrapped into an object in order to avoid unnecessarily dumping large amounts of data into the Grasshopper UI when it’s not needed. You can access all of the data using the “LB Deconstruct Matrix” component like so:

You can see from the time it takes to run each component that not dumping all of the intersection data into the Grasshopper UI cuts down the overall runtime of the component by a half. This way, your script only takes a long time to run in the case where you actually need the sunIsVisible data.

1 Like

Dear @AbrahamYezioro,
stupid me, I had already tried to graft the geometries, but from the wrong input.
Thank you so much for the advice.

Dear @chris, thank you very much for all your detailed explanations. About the “int_mtx” output, I don´t notice the clear description inside the component.

About the Hoys, via the “DateTime”, I have found a problem, which perhaps is what @devang, had also noticed.

as you can see in the screen, the right minutage does not appear in the list, why always shows the same time, (7:00 for 60 minutes, 8:00 for 60 min, etc, etc).

I attach the file, so you don’t have to recreate it. (32.2 KB)

Thank you all for your kindness and your support

Liam. R

@LiamRuvio ,

Good catch! The _hoy input on the “LB HOY to DateTime” was casting the input to an integer instead of leaving is as a decimal value. I just merged a fix into the official development version of the plugins:

But all that you need to do for your file is right-click on the _hoy input, go to “Type Hint” and select “float”. Then the minute values all display correctly: (30.0 KB)

1 Like

Thanks for all @chris!!

Hallo dear @chris,

maybe I noticed a strange thing with the “LB_deconstructionMatrix” component.

I have analyzed for my test-workflow, two exactly surfaces with 25 sensor points for each surface.
For this case I have 306 sun vectors.
As you can see from the screen,

out from the XMatrix, I don´t have 2 grafted list, one with {0;0 to 0;24} and one with {1;0 to 1;24} for the SunIsVisible of each surface, but the component appears to flat together the same index of the two lists.
In fact, each (sensor) index instead of having 306 vectors, has 612 vectors.

So I have difficult to select the result of the sunisvisible, of a given sensor of one of the 2 windows.

I hope I haven’t got something wrong.

I attached the example: (62.5 KB)

Liam R.

@LiamRuvio ,

Admittedly, I could change the “Deconstruct Matrix” component to output a full 3D matrix for cases like this but it will increase the runtime and I am not sure that a 3D matrix is really desirable here as it will mean that certain operations with the data will not be do-able (like writing the data to a CSV).

So, before I consider making any changes to the behavior of the component, what do you think about the following possible solutions:

  1. If you are only going to have a small number of surfaces (like the 2 surfaces you have here), you could just explode the tree of matrices (you have one matrix for each surface) and pass each through their own “deconstruct matrix” component:
  2. If you really want to have a single data tree representing the 3D matrix, you could partition the output of the “deconstruct matrix” component using the length of the list of sun vectors:

    You can even use the native Grasshopper Path Mapper component to put the index of the surface first in the path before the index of the point: (64.2 KB)

Are either of these alternative solutions going to be suitable for your case here?

1 Like

Dear @chris,

I had already tried your first solution, before writing to you, but don´t satisfy me, instead your second solution solves the problem very well.

as always, thank you for your time and your precious explanations.