Hi everyone,
I’m really new in grasshopper and I don’t really know How to do my stuff
I have a rhino map with curves wich are Buildings, from an illustrator.
And I want to display buildings, according to space inbetween
For examples if there is more than 50 meters between 2 buildings, they will disappear
bati isolé.3dm (6.7 MB)
Thank you for your help!
You mean that you want to find all Curve to Curve min distances?
If so and if the layout is planar do the following entry level stuff (and we talk later for the “perfect” solution): get the Curve/Closed Polyline centroids and do a classic delauney triangulation (EDGES not MESH).
Then using something the likes of Sandbox you can have control on the 3 connectivity trees related with P(oints),L(ines).
This allows you to have pairs of curves based on LP connectivity indices (since centroids are due to curves their indices are 1:1 to curve indices). Then find the min Curve to Curve distance (per pair), and then do whatever you like.
If you want an example on all that freaky stuff as above notify (I’ll make a rare exception: this could be carried over viai components and not code).
BTW: Plan B (without triangulation) if to perform a proximity search (using the , say, curve center points). There’s a native component that does this and since it outputs connectivity data and since center indices are the same with curve indices … blah, blah
That said I have a C# that does what you want with 16 different ways (2 methods * 2 modes * 4 search options) but it could be useless to you if you don’t speak the language.
Maybe the plan B seems to be more userfriendly
Could you let me try with your file?
Well … get it but these things are either Nirvana and very user friendly (case C# fluency) or Hell (the other thing).
Curves_DelauneyConnections_V1.gh (140.6 KB)
Note: programming differs vastly from doing stuff with native components since the latter is more or less some sort of language whilst the former is a dedicated (occasionally high performance) solution targeting a very specific problem. This means between others that if your polyline collection IS NOT the sort of thing that the C# expects to process > garbage in > garbage out. This is not an issue at all if you can modify the code (usually for a “similar case” takes a couple of minutes)… but you can’t since you don’t know how. .
Note: Sandbox is required (for method 2).
Moral: May the Force (the dark option) be with you.
I didn’t get all what your mean, because i’m french, but I did some stuff, and I manage to get what I wanted to frm the centers of the curves. But it seems to not work as I want
But I think the better method will be to use extern points of each polygons, but this is much more complex I think and I didn’t manage to get it.
Thank you anyway
That makes 2 of us, he he.
Note: As I said Nirvana and Hell are that close. Anyway the thing posted (already existed for other purposes) extrudes curves based on the value returned according one of the 16 combos available (method/mode/etc). If you still like to give it a spin I should modify a few lines in order to get something that corresponds to the footprint (either the curve or a 3d thing). For big N of curves // programming is maybe a must (if you have cores aplenty).
I have a feeling that connectivity trees are a bad thing for you. Here’s Part 1 of a solution using native components and no mysterious C# and other freaky stuff. Requires an understatement of these @%@% trees … thus study the attached and have faith (for Part 2,3,…).
Curves_ProxConnections_V1.gh (36.1 KB)
In fact this approach (using a “delegate” so to speak for the curves [ the centers]) is not 100% correct since actually we should search for prox curves instead of performing prox search on centers … but that’s not the point at this Part 1 phase.
Anyway a hint on that matter: See this:
More soon
And this … er … is Part 2. All the stuff found in Part 1 is deactivated and despite promises code is used for finding prox curves within miin/max distances (see 2 for that).
Curves_ProxConnections_V2.gh (85.2 KB)
Study the results (and the synchronous sort), what they mean and … hmm … the unavoidable curve to curve connectivity tree (that differs from the Point to Point “equivalent” tree derived from the native GH prox thingy [that uses a very fast special collection named Point3dList, but anyway]).
Problem is that this is considerably slower (for good reason) meaning that in real-life (big or very big N of curves,llike in your case) some sort of // processing is required … meaning code. Note the // part is not (yet) implemented.
And this is Part 3: a hybrid approach using the speed of the Prox GH native thingy in order to locate a bunch of “candidate” prox curves and then it process only these in order to get the ones satisfying the min max criteria. It does that because the curve indices and their centers indices match 1:1 so the connectivity returned via the Prox actually is the Curves connectivity as well.
All these mean that you must study what connectivity trees are.
Since it’s based on the Prox it can handle big N of curves before things are going bananas via // stuff (finally not required for samples the likes of yours [1-5K of curves and some decent i7 CPU - Note: one core working the other(s) are doing nothing]).
Curves_ProxConnections_V3.gh (41.0 KB)
All the job is done by 95% via native components,
The pros are obvious … the con is that the final (min/max) filtering is based on results from the Prox … meaning that the handling of the def may become slightly confusing,
And this is the final thing:
Curves_ProxConnections_V3A.gh (60.0 KB)
Insofar the 3 as above lists match 1:1. Any given index targets footprint/center/building
Why ignoring the GH native component that finds just one prox curve? Well … in order to avoid the Abu Dhabi nightmare: a single closest curve means nothing … the density means everything [see Dubai as well]).
