I am using the Solar Envelope component and it is much advanced than before, congratulations for the work. But it still present some limitations. I mean the input _sunVectors limits the use of the tool at one building per time and it is even not very efficient. For example in a situation like the image I attach I have four buildings facing the area on which I need to calculate the solar envelope that guarantees 2 hours of direct sunlight on all the surrounding facades. If I have to input the sun vectors that guarantee 2 hours insolation for the South facing facade (from 11 to 13) then the solar envelope is most likely not correct for the East and West facing facades and it totally null for the North facing facade. So the suggestion is to develop further Solar Envelope component and add to the _sunVectors input also another input for the required minimum hours on specific facades. Thank you!!
Hello Francesco, thanks for the comments and sorry for taking a while to answer.
If I understand you correctly, you want to have the option to set different parameters to different facades. What is not clear for me is guaranteeing a certain amount of sun hours as the logic for the component. The way the component is working now, sun access is guaranteed to all facades given the specified sun vectors.
We’re working on an improvement to also take into consideration the angle of the sun relative to the facade, I think that could be relevant to the example you showed -
Another approach would be to run the solar envelope component with different parameters (for instance different sun vectors) and then combine all the envelopes to one. In this example I’ve added a component which does that - http://hydrashare.github.io/hydra/viewer?owner=boris-p&fork=hyd…
I’ve combined only two envelopes but it should work with as many envelopes as you want, the HighestEnv parameter is a boolean, if true will give the combination of the highest points and if false the combination of the lowest points for all the envelopes.
Let me know if these improvements are helpful, or if something isn’t clear.
thank you for the reply, don’t worry, for me took a while to check back here. it is interesting what you say, actually I also developed something similar to what you did (but ok you did a component I just used different components and GH tools to do the same - and this become part of my short paper submission for SimAUD 2016). My solution compares the height of the same points of different solar envelope and then chose the lowest one. I read about the improvement you are working on and it is good but I think it is not yet what I need (or how the solar envelope tool could be more complete).
What I need is a solar envelope that would guarantee on different facades with different orientations (the example I sent you) a certain amount of direct sunlight, say 4h per day in a given period for example all the month of June at 60°N. So to guarantee the south facing facade I should chose the vectors from 10 to 14. But these are not ok for all the other facades because in this timeframe the East and West facing facades get only 2 hours and the North get 0 hours.
So the fist step would be have the possibility to chose different sun vectors for different facades. For the example I did (the 4 hours in June at 60°N) the south facing facade would need from 10 to 14, the East facing for example from 8 to 12, the West facing facade from 12 to 16 and the North facing facade from 6 to 8 and from 18 to 20.
If I would chose a single longer time frame that could get all these hours, from 8 to 20 then the resulting solar envelope would result probably smaller than the sum of the four solar envelopes.
But this is not complete yet. I mean the use of different sun vectors on different facades. The reason is that for example when I chose the sun vectors from 8 to 12 for the four hours on the East facing facade how do I know that the sun hit on the facade in that time frame or maybe it is obstructed by surrounding buildings? Since the sun at 60°N (where I live) in June rise at around 3.15 then maybe for that specific facade the sun hit from 4 to 8 and not from 8 to 12.
I did an extreme case talking about 60°N and that maybe the sun hit on a facade at 4 instead than 12, but it is just to make understand the logic. My suggestion for a more advanced solar envelope it should be integrated with the Sunlight Hours tool of ladybug. So the input should not be the sun vectors because I don’t know when the sun hit on the facade but the input should be just the desired number of hours and the possibility to specify different number of hours for each facade. Then this last component that sum different solar envelope (I didn’t use it yet but I understood what it does) should be integrated yes so the result would be one single solar envelope more likely using the lowest points (the highest I don’t understand what for).
Hello Francesco and sorry for taking a while to answer.
Regarding the situation you’re describing, I can see it as useful and with the component I sent you or with your solution it’s attainable (just a bit more work). Extending the component to act the way you describe might make it a bit complex as it is very specific. The other issue would be that it introduces a degree of freedom. Imagine that you’re providing a list of sun vectors and also a specification that a certain facade must receive 4 sun hours. If there are 10 sun hours in the sun vector pool then what does the component do? take the first 4? take the 4 with the biggest altitude angle because that would (probably) create the biggest envelope? look at the radiation and choose the 4 hours with the most radiation? and so on. The user has less control and knowledge as to what actually happens which is something I tried to avoid for this stage.
Now what if we have more than 4 orientations or the building is not aligned to the north? How accurately will the envelope represent the actual requirements then?
Having said that, I agree that the user might want to simply say, I want so and so hours or so and so radiation on my facades, give me an envelope which does that, currently it’s not as direct.
Regarding python vs gh, I think that at some point you reach a glass ceiling using just visual programming, but of course it all depends on what you want to do…
thank you for your reply. I know that it is not possible to make a component for every specific need people can have, don’t worry I think you guys are already making a big work.
Anyway I was not thinking to have two inputs one for the sun vectors and the other for the quantity of direct solar hours. I think, but this is just my case for the requirement I work usually, that would be interesting to have the possibility to work with a solar envelope in which the only input the quantity of direct sun hours. So no sun vectors at all. So the solar envelope should first run a sun light hours calculation (like the specific component does) to analyse every single facade then considering the surrounding should then find the best solar envelope. I see this more a thing that it could maybe possible to achieve with the generative design tools.
Hi Boris,
what exactly do you mean with “sun access guaranteed to all facades”?
Let`s say I use sun vectors from 7am - 9pm. Is the Solar Rights Envelope representing the volume so that all sun vectors will hit each facade?
