I’ve been using Ladybug View Analysis to determine whether a feature within a city (like the Space Needle in Seattle) is visible from points on a building, like so:
This works technically, but if I am testing to see if people inside the building can see the feature, it breaks down. This is because the test point on the surface of the building does not care if the angle between the test vector and the vector to the feature is too great to actually be visible from inside. I drew a diagram to demonstrate what I mean:
In theory,I would like to test to see if the angle between vectors is above a certain degree (likely just a “good enough” average based on window width and wall depth), and to register any test vector above that angle as obstructed.
I feel like, with enough kludging in python, this would be achievable, but the scripting for Ladybug is daunting to an amateur like me. Does anyone have any ideas how to get this to work either within the python code or by manipulating the results?
Thanks,
Shane
Hi Shane,
This is a fairly complex question could you please attach your GH file? Once you’ve attached it I’ll try to get back to you with an answer by the end of next week.
Hi Shane,
This is a great suggestion. Since the view analysis is very subjective it is really hard to come up with a solution that address all the issues. If I remember right the very first version of Ladybug actually had a viewAnalysisPar that would let you to set the viewFieldAngles. Also all the view points used to be weighted based on the angle.
The feedback was that this is not the right way of measuring the view. For example people can turn their head around, and also they don’t really seat perpendicular to the window. In many offices the layout is to sitting parallel to the window and in the case you will be actually seeing the point in the off angle. Then I removed the input and added waiting factor, but there are cases like yours that it won’t be useful.
All said I personally can see the value of having a field of view input or an output for all the angles which can be used to remove the points afterwards.
Let me know your thoughts.
Mostapha
Hi Mostapha,
Thanks for replying. I think in a residential situation the acute angle is a bigger issue than offices since rooms and windows are smaller in residential areas. What I guess I’m trying to simulate is someone standing a foot or two from their window, drinking their morning coffee and enjoying their view of the nearby mountain or body of water or whatever landmark is interesting in the area. I realize I’m sort of using the component backwards, but it is really useful in the context I’m applying it in, it is just returning un-realistic results in some situations (where the space needle is 98 degrees off the normal of the window, for example).
The weighting factor could also be folded into this, views closer to normal get more weight for example. In my firm I’m asked to produce this analysis a lot, but I hate giving caveats about this angle issue. It also returns counter-intuitive results, making our shaping of the building seem less impactful than it really is.
Anyways, that is my 2 cents. I might bone up on my vector maths and see if I can’t crack it.
Thanks!
Shane
Hi Shane,
I just wanted let you know that Chris has recently added a number of new functionalities to the view component that addresses some of your concerns about calculating the view. It’s still under development but I thought you might be interested to give it a try.
Mostapha
So I finally decided to take a crack at fixing this issue, and created a bundle which plugs in to the back-end of the ViewAnalysis component. It takes a acceptable viewing angle from the analysis’ surface normal (ie, 70 degrees from normal will result in a 20 degree non-viewable angle, or the “user defined” note in the sketch in the original post). The view angle is a cone, so it doesn’t mimic the new view angle component for Ladybug which alters the cone based on up/right/left/down.
It returns the analysis mesh (in black and white, but that is just a gradient component in the bundle), viewStudyResult and averageView. I’ve found this makes a huge difference when analyzing a buildings view potential to features and landmarks.
This seems to work great for my particular use case. If anyone has ideas to improve performance (it is kinda slow) or other comments, I’d like to hear them.
View analysis - Restricted Angle.gh (401 KB)
This is fantastic, thank you!! Works fine for me, doesn’t seem to add much time at all onto the analysis process.
Hello all,
I am performing a view study similar to the one Chris Mackey has presented in this video https://vimeo.com/ondemand/performancenetwork/191610487?autoplay=1.
At 1:25:00 frame (as per image down below) he showed where the vectors come from for an analysis referred to a surface test.
My question is: why the position of that vectors is at an angle and not in the center of that surface? is it automatically generated from the component itself according to specific parameter that it is not shown in the component?
Furthermore, the distance from base has to be taken in order to reproduce the height of the eyes? In this case the height of the surface plane can be selected at the aforementioned height without using distance from base?
Thanks in advance
Luca
Is your bundle still available to share? When I click on the link in your post, it says that it is no longer available.
In theory,I would like to test to see if the angle between vectors is above a certain degree (likely just a “good enough” average based on window width and wall depth), and to register any test vector above that angle as obstructed.
