Hello everyone,
I am trying to extract the surface area of building according to the Azimuth angle. (Surface area according to orientation: surface area facing north, south, east,west). So far I have Deconstructed Brep and I get the surface areas but I can’t sort it according to orientation.
Has anybody ever tried it before or know any plugin that does it?
Cheers,
Bhumika.
Hi,
There is a component in LB Tilt And Orientation Factor which output this PVsurface Azimuth PVsurfaceAzimuth Orientation angle of the inputted PV_SWHsurface. In degrees (°).
Check this it might be helpful.
Cheers,
BVR
I’m not sure this is what you’re looking for but the blue outlines in this image are the cross-sectional area of the shadow at different sun angles:
From here:
Also, this one might be useful?
Hi @ajarindia
I tried this, but here the _PV_SWHsurface takes only one surface at a time and runs a whole analysis for PV (ultimately taking a lot more time to calculate angle). It is spending time in calcualtion that I don’t require. I need to figure a convenient way for that.
Thanks for the suggestion though.
Hi @Joseph_Oster ,
All of this looks very cool, but unfortunately not quite applicable for my case I guess. All I need is azimuth angle of surfaces.
Thanks anyways.
Cheers
Are you sure?
Perhaps if you posted a GH file with your geometry at the very least, with an image to explain clearly what you are looking for, expected inputs and outputs, etc… What I posted is needlessly complex but I suspect it’s closer than you think to meeting your needs.
Is your building square to the XY axes? No consideration for time of day (Altitude)?
Here is the image of geometry (IMAGE2). I have deconstructed it, and then I calculate the surface area. In the list (list of surface area in image1) I get surface area for all the surfaces in different direction including the floor and roof which are 1463.67) The main problem is I need to sort it according to orientation. like for example there area two surfaces facing south (azimuth angle = 180). In the shown list they area (280.2 and 105.2 have azimuth 180 and are facing south)
In short my input will be surfaces (DeBrep as seen in image1) and my output needs to be the azimuth angle.
I hope this clears my problem.
Yes, the image and extended description help a great deal. Please post your GH file with that geometry?
Geometry_feature_extraction.gh (29.6 KB)
This is the Gh file.
I need to record this data for further analysis. and I run this in a loop for multiple breps, hence I need a continent way to store this info.
That’s a different issue… The model I posted separates East, West, North, South, Top and Bottom surfaces. If the top isn’t flat, it might fail…
Wow, this looks perfect, exactly what I wanted to do. One problem thought is that Evalsurf from any plugin? I think I don’t have that installed.
No, it’s a standard GH component.
Ya, I have got that looping part figured I just needed what you did, separating east, west north,south, top and bottom. Perfectly executed. Many thanks.
Unfortunately it doesn’t work with a list of Breps, only one at a time. That’s not good Grasshopper!
Not sure what to do about it… 
Looping is one way to handle it, I guess, if you can record the info each time through the loop.
This is really ugly to my eye but it works. Each branch of the outputs (East, West, North, South, Top and Bottom) corresponds to a separate building. It should handle a list of many buildings, not just four.
Three copies of a cluster would clean up this code.
Clustered! vSrf contains the repeated code.
NOTE: Version 'c2’
Inside the vSrf cluster I added the expression “round(x)” to the DProd (Dot Product) output so the code is less sensitive about exact alignment. To test it, I added the Rotate component.
Thank you so much for all your extra effort to clean up the workflow but the First workflow you posted perfectly worked for my previous workflow. I can now record surface area with all orientation. I have a code that clears the window every time the data is changed, so every time it iterates over a new building, the previous model is eradicated. So the first workflow worked perfectly.
The “round(x)” expression in version ‘c2’ is important and it still works fine one building at a time.
You’re welcome.
Consolidated further into a single SrfDir cluster. No changes to algorithm from version ‘c2’.
The yellow group offers a choice between one or “many” buildings and the ability to rotate them.
