Sorting Points from 2 Lists based on their vicinity

Replies to This Discussion

Permalink Reply by Oliver Hampel on July 20, 2016 at 12:07pm

Since I am talking to someone with the Force... I am using this definition quite a bit, but it is so slow... it is used to find the centroid of a closed curve and unifies the plane normal for all curves. You wouldn't know a way to speed this thing up would you... a spare time challenge!

Oliver

Attachments:

• Centroid-Plane-Normal.gh, 327 KB

Permalink Reply by peter fotiadis on July 20, 2016 at 12:19pm

OK, that's a nice w/e challenge (but I hate laptops) whilst waiting for some proper wind (wave windsurfing).

Permalink Reply by peter fotiadis on July 21, 2016 at 5:16am

With regard THAT ... er ... Centroid-Blah-Blah thing of yours (what was that? a test for the brave?):

Good news: solution is accelerated by a factor of 1678,784 (if memory serves well). Still WIP and no parallel processing, mind. For the Curve vertices the notorious HocusPocusLocus (Tm)(C)(US patent pending) method is used.

Bad news: No plane orienting policy applied yet: explain (like talking to a stupid robot) what scenarios suit your goals.(Hint: do you want the curves become clockwise?).

Ugly news: No wind this w/e: life sucks.

Load R file first and DO NOT internalize this type of stuff (tears on sight the one or the other way).

Attachments:

• CentroidPlaneNormal_V1.3dm, 637 KB
• CentroidPlaneNormal_V1.gh, 130 KB

Permalink Reply by Oliver Hampel on July 20, 2016 at 12:23pm

I see... you look awfully relaxed there... You enjoy your maithai and catch some waves... Thank you for your help!

Permalink Reply by Oliver Hampel on July 21, 2016 at 7:18am

Good (Dark) Lord, 

Awesome Stuff... So many questions...

For output why use Datatrees instead of Lists? I assume it makes sense to place the info into a rhino kind of data structure directly but what is the benefit?

BTW: go easy on the Tequila and Vodka

On the GetNextDiscontinuity part. How did you figure to use C1_locus_continuous = 7... where can I read up on this?

Just digging through the stuff you threw at me... I will get back to you. Thank you Peter

Permalink Reply by peter fotiadis on July 21, 2016 at 7:58am

Well...

1.We have N Curves each one of them may have a variable amount of HocusLocusPocus (HLP) pts > therefore only a "higher" order thingy can store that type of stuff: and the GH way is a DataTree. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.

2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.

3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).

4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).

5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).

Permalink Reply by peter fotiadis on July 21, 2016 at 8:17am

BTW:

Permalink Reply by Oliver Hampel on July 21, 2016 at 9:59am

what was that? a test for the brave?... man you are brave - this thing you wrote is lightning fast... do not know what to do with all that extra time - I guess I go surfing. Thanx

Permalink Reply by peter fotiadis on July 21, 2016 at 10:37am

Well ... surfing is a far more serious thingy than C# ... but ... if there's no waves AND you want big (literally) response times I could add a proper variable for the job (kinda like the 0.7 to 600+ ms on the other case of yours, he he).

BTW: Assuming that the final scope is the obvious ... have in mind that the path is long (and hilly). I don't want to mimic Kassandra ... but consider a faceted dome for that kind of stuff (real-time solution from step 0 to 666).

Permalink Reply by Joseph Oster on July 20, 2016 at 9:22am

Not at all clear to me what you are trying to accomplish?

You have two lists of 176 points each, but only 240 unique points between the two sets.

What is your goal?  "based on their vicinity" doesn't say enough.

Permalink Reply by Oliver Hampel on July 20, 2016 at 9:36am

It's the 2 of us again... you are right in hindsight my question was not clear. I am trying to create 2 index/list of the points inside the sphere. 176 points are used to draw spheres. each of these 176 points has one close by that is within the sphere. This makes 176 pairs of points. I need to sort these points to have the same index.

sphere1 - list1point1 list2point1

sphere2 - list1point2 list2point2

sphere3 - list1point3 list2point3

and so on... see new attached file.

thank you,

Oliver

Attachments:

• Point-Sorting-New.gh, 15 KB

Permalink Reply by peter fotiadis on July 22, 2016 at 4:15am

For the other thingy of yours (Centroid), found a couple of minutes for the trad update.

V1A orients (if desired) the plane Z axis outwards ... but it doesn't do anything with regard X/Y Axis.

V1A is rather more intelligent (vertices List => it detects Polylines that are way faster to process: use the 2nd demo and see the serious gains in response time [ 1 to ~5] and all that without checking planarity [i.e. using always the Plane fit to pts method]).

5 ms for 180 polylines:

22 ms for your Curves:

BTW: Added a "viz" planes demo by orienting something.

Attachments:

• CentroidPlaneNormal_V1A.3dm, 588 KB
• CentroidPlaneNormal_V1A.gh, 135 KB

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