sightlines problem

Hey everyone. There's probably a better title for what I'm trying to do, but let's just call it "sight lines" for now... imagine an urban plan, I want to generate a graph that will color-code the street layout by density... here's a start - i've gotten sightlines from one point to surrounding curves... I'm trying to enhance the definition to work with multiple points, but running into data path problems. does anyone have a good idea how to resolve this, or another way of doing it?

Attachments:

sightlines.ghx, 142 KB

Replies to This Discussion

Permalink Reply by Boris Rüther on April 7, 2011 at 7:39am

hi evan,

i think the attached ghx shoot be the solution.

greets

boris

Attachments:

sightlines_110407.ghx, 392 KB

Permalink Reply by David Rutten on April 7, 2011 at 9:52am

Cool, you get the curved lines visual illusion like this :)

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by peter on September 24, 2012 at 7:56am

cool...

I have been trying to do something with intersections but it;s way to slow ...

any way of defining a target, ie. that the rays don;t go in very direction but only towards a specific target, ie. a projection screen?

thanks,

Permalink Reply by David Rutten on April 7, 2011 at 9:47am

Hi Evan,

they are called Isovists. I had a go at making it multi-point capable, but there's so much overhead that I decided to write a 2D isovist component. It's still dog-slow (attached image took almost 60 seconds to compute, 50x50 points x 35 samples each x 3 rectangles = more than a quarter million curve|curve intersections), but at least not fossilised dog slow.

The inputs of the component are:

P = Plane in which to shoot the isovist sample rays, plane origin equals sample point

N = Number of rays per sample point

R = Maximum radius of sample rays. Any obstacles beyond the radius are ignored

O = List of obstacles (curves only). They will not be projected onto the sample plane, so you can have curves that are only partially 'active'.

Outputs:

P = Point at end of ray (at distance R from sample point) or point at closest obstacle along ray view direction.

D = Distance from sample point to P

H = Boolean indicating whether the ray hit an obstacle or not

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on April 7, 2011 at 9:51am

ps. I think I have some ideas to drastically speed up the calculation, but they'll have to wait until more serious bugs have been addressed.

pps. I also added a single-ray component, so you specify a line (representing a semi-infinite Ray) and a bunch of curves and it will return the intersection closest to the ray start point.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Marc Syp on April 7, 2011 at 11:47am

Very cool... yours is much prettier than mine...

Attachments:

Intelligibility02a.ghx, 474 KB

Permalink Reply by Marc Syp on April 7, 2011 at 12:50pm

Followed your lead and painted a mesh instead of using spheres and lines... not bad. Image below uses 30x30 sample grid, 35 rays per point.

Permalink Reply by peter on September 24, 2012 at 8:48am

cool.

Any way of using this in 3D Space at all?

Permalink Reply by Evan C on April 7, 2011 at 7:24pm

wow. fantastic! thanks for the help, everyone, this is exactly what I was trying to do.... now I just have to dig through your definitions and see how its done.

David, do you think this will ever be fast enough for "real-time" updates - or is it just too many intersections for that?

Permalink Reply by David Rutten on April 8, 2011 at 3:18am

My main idea is to stop using intersections at all. As you may know OpenGL uses a Depth Buffer to make sure that objects in front of other objects are drawn correctly, regardless of the order in which they are drawn. I was hoping to implement some sort of one-dimensional depth-buffer for every point of view. This would then give you a large collection of distances mapped around the panoramic circle. If this can be achieved through OpenGL chances are it will be realtime, at least for a single sample position. Let's say I manage to get it down to 5ms per sample, then it would still take over 10 seconds to do a 50x50 mesh grid.

I have no idea if I'll be able to pull it off, it's definitely unlike anything I've done before. There would also be a small sacrifice in accuracy, but then with a small number of samples (<1000) you have low accuracy anyway.

The way the component is set up makes it difficult to optimize for many samples, though that would open up other possibilities.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Marc Syp on April 8, 2011 at 9:39am

That OpenGL solution is really creative and would be fantastic. We are hoping to implement an Isovist representation at an urban scale, so obviously the minimization of processing power required would allow us to increase the resolution in an inverse relationship. Of course, if you don't get around to it any time soon we'll just work with intersections... :)

Marc

Permalink Reply by kwanphil cho on November 16, 2011 at 11:14am

David,

Hi. I know that it is bit of old post but are there any improvment for this? I have been trying with the definition that you have been uploaded but it is virtually impossible to compute visibilities when it comes down to the scale of Masterplan. Or Do I miss something important? Thanks.