Hello dear @mikkel,
Thanks for the awesome and long waited component.
I have notice 2 strange things, in the hope that maybe I’m wrong to understand.
The first is that if I using a Schedule, the occupancy hours of the annual plot is not congruent with the given input. I used a normal office occupancy, but as you see, there is something wrong.
The second question is that I have noticed that is not possible to read the numbering of each “piece of cake”(orange marked in the image below).
The text of the numbering of the 8 segments is overlap on the center of each sensor.
I think this create a bit of difficulty in selecting the result of a particular sensor.
This also doesn’t allow me to show the value with a text of into each piece of cake.
Could be an idea to be able to get a numbering to each piece of cake (for example in your old script in HB+ I did it with Mesh Area → Centroid and then connected with Point List) and then bring the right numbering into each annual plot, to understand even each annual plot which direction it is equivalent to?.
The schedule issue is likely because you do not have the latest version of the recipe. Please update with LB Versioner and run the recipe again. Short story; I removed the schedule from the DGP calculation, and now the schedule is only used to calculate GA. That’s probably why you see those gaps in the annual plot - because the schedule set the values to 0 in the first version.
@chris is probably the person to comment on the last question, but it is possible to construct a custom header and connect the sensor number if you find this manually.
Yes, that’s the right idea with using the LB Versioner. There have been a few updates to the recipe since the first version and the last major one for the schedules was made last Thursday.
Dear @Mikkel,
thanks for the clarification. I hadn’t thought about the component “Face Normal”.
I also noticed that using the LegendPar, I have a problem of tonality gradient in the coloring of the results.
I used a legend from 0 to 100% with a color change every 10%.
As you can see per example the “piece of cake” with 73% and 79% I have a different color, as well as 91% and 99%, instead it should have the same RGB.
Hi,
One more option for numbering the sensors together with the GA results (I like better to have them from 0 to 100 instead of 0 to 1, but this is me … ).
Thanks for the tips Abraham,
but look you have the same problem with the coloration.
Per example the piece 56/57 or 105/111 they should have the same color. I tried using the Legend Parameter Categorized, but nothing, I have the same issue
I think there is no problem. Think about this like the color scale is a transition between values. The coloring is not that everything between some limits (say 70 and 80) will have the same color. Values closer to the high limits will have a closer hue to that limit.
Something like this:
Hallo Abraham, yes but you have set now a color gradient and so it is correct, but if you use a not continues legend or a categorized legend, this shouldn’t happen. The value within a certain range must have the same color.
Your sample was not using Legend Parameters Categorized for the Glare Autonomy visualization. Here is what it should look like if you want the colors to display categories instead of a continuous spectrum of colors.
the result says that the view 685, for 97% of the hours, is free of glare, but when I see the Annual Plot for the sensor 685, only 4/5 hours suffer from disturbing glare. In that case the result should not be 99%, instead of 97%?
It is a doubt that has arisen because in many views, completely opposite to the windowed surface, I have a percentage between 90 and 96% of free of glare, instead of being close to 99%, since only little reflected light arrives on the view.
For this type of analysis which Radiance Recipe Type do you recommend to use? rpict or rfluxmtx?
You have to keep in mind that Glare Autonomy uses and occupancy schedule just like Daylight Autonomy. The default schedule is between 9AM-5PM, which is really only a third of the time in the entire day. So it makes sense to me that a view which is glare-free for 99% of the year is only glare free for 97% of the time between 9AM-5PM.
If you want to do away with the default occupancy schedule, you can always create a constant schedule with a value of 1 and use that for the glare autonomy analysis.
Hello @chris,
I have activeted my Occupied Schedule, in this case from 8AM to 17PM, and the result goes down to 94%.
If you see, only 4 occupied hours, perceives a disturbing glare.
I have now 2610 occupancy hours, 4 hours out of 2610, should be close to 100%.
I looked at the raw results and at first I was perplexed until I realised that we left out some positive hours (glare free hours) in the current calculation. These positive hours are hours that are within the schedule but not within the sun up hours. This means that they were not considered as glare free hours. The reason for this mistake is that the GA calculation is based on the code for the DA calculation, but the difference here is that hours with no sun are bad for DA but good for GA since there is no sun = no glare.
I merged in a fix that will make its way through to the recipe later today.
FYI @LaFleur and everyone else, the fix should be available by updating the core libraries with LB Versioner. You should see that views with glare free hours only will have a GA of 100%.
Hello @chris and @mikkel,
I have a last question, how can I read the DGP value of every single hour (8760) from the selected view, out from the AnnualToData component? The output says “These can be visulized using the ladybug components or deconstructed for detailed analysis with native Grasshopper math components.” but I don´t understand how component should I used.
I make a comparison between the results of the annual imageless Glare plot and the single DGP value using the PITView. I do only with 3 days (15Mai, 01 Juni and 06 July) and I found some inconsistencies.
As you can see, for example, in the first 2 days, the intolerable glare starts an hour earlier (at 7AM and not at 8AM)
In the analysis of July 6 instead, in the annual plot we have at least 3 hours of disturbing/intolerable glare, instead from the images only at 8AM.
What can these inconsistencies depend on? I know that I have not used the same detailed parameters of Radiance, because otherwise for the Fish-Eye images the times would be biblical, but I shouldn’t get to have all this difference. Some advice?
).
