Hello,
I need some creative help to solve that issue:
I wish to be able to cull points so that they would be aligned, even though the number of elements in each line is different.
I managed to do it by using an ordered grid and checking it with points in curve, but it was too slow…
Any other possible solution idea?
This is what I am aiming to:
ordered cull nth.gh (22.9 KB)
Hi. Thanks,
I was wondering if there is a way to do it without the “points in curve” component, cause it gets too slow with many points…
How many points are we talking about?
About 10k, the thing is that the point in curve takes 350ms and slows down the entire code… all this to get an aligned cull of points. ( it is the first solution at the top of the code).
I am trying to find a way to do it without that component…
Just to wrap up the subject- I found a way to do so… It still has some issues in the peripheral parts, but at the moment, it is better than the other options…
If you find a way to make it work on the lines that are not intersecting, let me know (:
ordered cull nth solution.gh (20.0 KB)
Your thing has some issues:
Anyway … just for the record see attached (an existed one [as a // challenge] … but it’s not useful - at all - for you since it’s pure code).
BrepFace_GridPts_V1.gh (123.7 KB)
Oh, wow. That’s cool! Would it be possible to make the input as distance between raws and columns ?
Very easy.
Right now it works on a per division basis meaning that it gets the union Box 4 points and then the bp[1] - bp[0] “step dx” Vector is divited by U (same for dy [i.e. bp[3] - bp[0]]/(double)V) and the new candidate Point is *p: orig + i dx + j * dy (see inside Method). I’ll provide an option for defining the Vectors amplitude via 2 values.
I’ add things/options as well related with your other goals (in PM) - for instance control on orig etc etc. But I’m not in the practice (where I have anything imaginable) plus I’m using an ancient laptop (only suitable for watching F1/MotoGP/WSB/BSB races).
Speed: well … this is one of my interview tests for people that I hire from time to time. So … other than a classic thread safe // approach the build posted (on purpose primitive/naive) is wasting a lot of time by looping the Faces in order to find an inclusion.
A classic way to speed things is to define Intervals on a per Face basis (“along” Face Boxes axis) and then use a pre-check: if point’s x/y are not in the search x/y Interval pair … then is not needed to elaborate further: i.e. use the PointFaceRelation enum final check. But if they are the final verdict is via the PFR
This could shrink Elapsed by “around” 20-30% (depending on the Face Topology for the FPR part).
Of course there’s Plan B: No FPR, just use the TrimAwareIsoCurve Method (not sure if this is faster - an “inclusion so to speak” test is also required - but it’s worth an option).
So in total and using a proper 12th Gen I9 I would expect 10-20 ms for ~10K grid pts (and Faces “more or less like” the ones used).
Sounds similar to (derived from?) this one:
Hi Joseph,
it is a somewhat similar scenario, as I saw the solution of Points-in-curve is way too slow for the code I am building… I figured out a solution, but it is not perfect, and @PeterFotiadis just showed up with a C# code that fits almost perfectly with what I need.
Update (// not implemented - useless on that ancient I5 available):
Added a pre-check. Fiasco: using far away - each other - test Faces (for obvious reasons: lot’s of missed hits) … but gain is a couple of milliseconds. Not worthy the 10 lines added to that miserable C#.
Moral: porca miseria.
Is this too slow and/or correct?
'Feels pretty fast here.
*Peter’s definitely faster, though - he exists on higher performance plane.
Not sure I understood what you were after but went for it from quick visual assessment.
ordered cull nth solution.gh (26.8 KB)
Update:
Well … using an Interview C# thingy is BAD: these are written deliberately wrong (for obvious reasons: the scope is to evaluate some sort of coding abilities [and pigs do fly]).
So for the update (WIP) and after a generous dose of spiritual aid(s) [lot’s of Tequila] I changed the whole logic/ flow and added an user defined origin point: i.e. origin is where the Red/Green guide lines intersect (spot that all Grid pts are “aligned” to origin).
Due to the Tequila … Elapsed is slashed by a factor of 10 to 20 … but there’s more tricks to use (as far as they are not internal).
Target (*) is 10 ms max for 5K pts.
So for the captured test … p to p dist in rows(U) is 0.30 and in columns (V) is 0.54.
(*): should I add some Jack Daniels to the spiritual situation?
BTW: you said: I vote for surfing as well… my kick are longboards (: That’s very bad: go buy a proper wave board (60-70 L) , do some life insurance, find a gale and give it a spin.
Update:
Mods asked: done.
Speed: finally I rated several Methods that slashed Elapsed time (like // or some other tricky/freaky stuff [notably: replacing the RC PointFaceRelation]) as internal ones: a thing like this is something that implicitly or explicitly has meaning in real-life. So get … er … a build that is faster (but not by much). This means that life sucks.
BrepFace_GridPts_V1A.gh (143.3 KB)
See the last C# as well (a demo for the path [i.e. the 2nd, 3rd dims] policy used). If you want to play games with your pts then I must declare the p Tree as nullable meaning easy connections/patterns/etc according any rule imaginable.
Longboarding is a lifestyle. It is my dancefloor 
What is your favorite surfing point?
The code works well, man! You know the craft. And really big thanks for the help.
Thanks.
This
BTW: most amateurs think that a // solution is the holly grail. But one should walk that walk AFTER resolving any bottleneck(s). In this case the PointFaceRelation is the big one: if your Crvs are Polylines there’s a faaaaaar faster way to cut the mustard (but it’s strictly internal: so it’s tried but removed from the posted build).
BTW: For your master plan and in order to define roads/parcels etc you need a nullable collection (i.e. accept items either as Point3d or null) : that way you can post process the pts (and create othro Polylines) very easily. All that assuming that you can manage 100% a DataTree. But that master plan Topology is a bit a Soviet thing.
Was just a cut and paste from zillions of C#'s (even on that ##$@#@ laptop).
Changed the terminology (and added skip/take in U/V). So … get the gist of the forthcoming V1B using this naive demo.
Plus … a few lines more are required: you want the “U/V gaps/voids” (controlled by skipU/V) to have different values?
So … if, say, skipV = 0 (for simplicity) AND skipU = 3 the gap values are 1,2,3,2,1,1,2,3,2… blah blah. Meaning that the skipU/V are Lists.
BrepFace_GridPts_SkipTakeExplain…gh (20.5 KB)
Say like this:
Hi Peter, The skip/take looks promising.
Would you share please the anticipated V1B? If possible to go back to divide lines by given distance you made in the previous version…
Cheers.
BrepFace_GridPts_V1B.gh (143.3 KB)
