Isolating unobstructed objects from a point

Replies to This Discussion

Permalink Reply by Joseph Oster on January 6, 2016 at 12:04pm

I'm not sure how to do this either...  But here is a different approach that preserves the data tree history so the connection between lines of sight and obstruction surfaces is not lost.  It's not the only alternative, of course, but the key is to NOT FLATTEN outputs along the way...  Instead of dividing surface obstacles to create lines of sight, this method divides 360 degrees by the number of sight lines you want to use, which puts collisions with multiple obstacles on the same line - in theory.

Attachments:

• 500mvisibleradius1_2016_Jan6a.gh, 48 KB

Permalink Reply by Angie on January 7, 2016 at 10:05am

Thanks Joseph, I am then not sure how to cull the lines which pass through more than one obstacle, or how to get a parameter input to shatter and then dispatch them. But thank you for the help I will have to spend more time looking at it and I think it will take me a while!

Permalink Reply by Joseph Oster on January 7, 2016 at 12:42pm

Hey, I think I got it!  I ended up turning all the lines into unitized vectors so I could filter out duplicates by passing them through a 'CSet'.  Then had to write my own 'Equals Zero Substitute' to filter the 'Crv CP' results, finding only the points that don't move...  Then for each line of sight, sorting them by distance and using only the first one.  Whew!  Perseverance furthers!!

Attachments:

• 500mvisibleradius1_2016_Jan7a.gh, 45 KB

Permalink Reply by Joseph Oster on January 7, 2016 at 4:16pm

This can't be the optimal solution... there are more than 400K points coming out of 'Crv CP' for 360 "Rays" (lines of sight).  Still, I tried to keep the data structure in tact by obstruction and surface (face).  While tidying up the code (attached), I noticed that I needed a 'Sort Pt' in the 'First Collision Points' group to get the points and subsequent lines in sequence.

Then, using the 'Tree/List Viewer' group (in attached code), I noted one unexpected tree at the 'path indx' slider value noted (~0.2). :(  These appear to be rays that would intersect the building behind it but hit the first building first...  Not sure yet why they aren't filtered out?

Attachments:

• 500mvisibleradius1_2016_Jan7c.gh, 49 KB

Permalink Reply by Matt Gaydon on January 7, 2016 at 5:34pm

Hi Angie and Joseph too.. 

I have a feeling you are looking for something like this? Using IsoVist Component, I realise its different to what you have posted and Joseph's answers but maybe its some help.

Cyan is Surfaces Seen/Hit

Purple is Surfaces Obstructed

Attachments:

• IsoVist Clash Check.gh, 12 KB

Permalink Reply by Joseph Oster on January 7, 2016 at 6:44pm

Yes!  "Isovist" is as good a word as any.  I don't have the Heumann plugin but it looks good:

http://www.grasshopper3d.com/video/3d-spatial-isovist

Still fun to try it in straight GH though."

Permalink Reply by Matt Gaydon on January 7, 2016 at 6:48pm

I maybe wrong as i have alot of plug-ins on my machine and back home now so can't check but i think the Isovist i used is a standard GH component written by David. Its only 2D but it works well.

Permalink Reply by Joseph Oster on January 7, 2016 at 8:13pm

Well, yeah, standard GH component - this looks promising!  (duh)

Attachments:

• 500mvisibleradius1_2016_Jan7d.gh, 55 KB

Permalink Reply by Joseph Oster on January 8, 2016 at 8:03am

This is very good Matt.  The only thing missing is a list of intersection points for each of the "Surfaces Seen/Hit" (a list for each surface), which can be constructed from the outputs of 'IVist'.

P.S.  Please ignore 500mvisibleradius1_2016_Jan7c.gh that I posted yesterday because I lost track of these points by surface in that version.

Permalink Reply by Matt Gaydon on January 8, 2016 at 8:43am

OK, still only 2D, but the code now also gives you all the collision points on the obstructing surface.  

Code in the Picture Frame is the update. (Member Index Added and another Item Component and the selected Components in Green too )

Currently the Surfaces are Items and the Points Branches, Though a quick graft of the main  Seen/Hit Surface list would make them both Trees of the same Number.

Also we have been talking in the office before about how best to do 3D Isovist on a city scale, still WIP so no code to share for that as yet.

Attachments:

• IsoVist Clash Check 01.gh, 37 KB

Permalink Reply by Joseph Oster on January 8, 2016 at 9:44am

VERY NICE!  I feel foolish spending my time yesterday trying to re-create this 'Isovist' component, though it was fun and I did get there eventually, or very close.

The only minor quibble I have now (because I wasn't clear before) is that it would be nice to get the results organized by building and then by face/surface...  This connection is lost when you flatten the 'DeBrep F' output?

But as this isn't my project, I'm ready to move on.  Thanks for the lessons!

Permalink Reply by Matt Gaydon on January 8, 2016 at 4:29pm

Ok this is the final one from me for now as knew it should not be too hard to access the tree data on the other-side. Joseph commented on which is a valid pt as knowing what building it is in the city can be very useful. Its a bit of a re-write but not to much has changed.

On the topic of sloping site one option is to rotate/define the input plane plane so it to slopes parallel  to the face of the slope as if you were tilting your head to look up or down..

Realised I did not answer you question about getting the end points of the obstructions , Its in the Red group in the code. Its set per building but if you want it per Face just press the connected switch. 

Ps. Joseph. I have worked on complex GH Codes before, only for Components to be created a few months/years later that making what I have done not as specialist, but at the time I learnt so much I am fine with it.

PPS. If you get an email about another reply and can't find it i delete it as it did not let me edit it in time.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page