Bit late to the party here, but here’s a good speed-up if you use the same curves(s) over and over again.
Measure the boundingbox of all the curves you’re testing.
Set up a transformation T_{map} from World XYZ onto a 2D rectangular domain of custom width w and height h, say w=1000 and h=1000.
Create a bitmap of w \times h and clear it so it’s completely black.
Transform all your curves from world space into bitmap space using T_{map} and fill them using white. You will not be wanting any anti-aliasing.
Then draw the edges of all the curves (again without anti-aliasing) in some third colour, for example red. Either use a single pixel thick pen, or maybe 2 pixels thick, you may have to experiment to find the thickness that never yield false negatives or positives.
At this point you have an image consisting only of black, white and red pixels with a distorted visual representation of your curves.
Now you can quickly test individual points:
Transform each point from World space into bitmap space using T_{map}.
If the mapped coordinates fall outside the bitmap dimensions (x < 0, x \geq w, y<0, y \geq h) then the point is not inside any curve.
If the pixel colour under the mapped coordinates is black, the point is not inside any curve.
If the pixel colour under the mapped coordinates is white, the point is definitely inside a curve.
If the pixel colour under the mapped coordinate is red, the precision of your lookup table doesn’t allow for an exact answer and you’ll have to fall back on expensive geometric testing.
Possible improvements to this scheme include the use of more colours. You could for example simply use the (A)RGB equivalents of the curve index to associate specific regions with specific input curves.
You will also want to lock the bitmap in memory if you’re using C# or VB, because GetPixel() on a memory bitmap is way faster than GetPixel() on a free bitmap.
@RadovanG it was also discussed earlier only additional step here is check if curve is self intersecting if is cut it in pieces join and mesh sepatate pieces then join mesh into one and cast rays to joined mesh one thing i didnt checked here is what if meshray would hit mesh backface cause indeed if user will pick tricky shape mesher could produce fliped mesh and next steps to find out where normals are pointing for sure can take down performance. I’ll give a shot with @DavidRutten concept also i think it really have potencial cause all points are solved at once and theres always result without going back and checking same points again.
If you work with mesh I would suggest to try with polyline as well:
covert curve to polylne-like structure
use algorithm to check number of intersections between ray defined by point and lets say y+ vector to detect if point is inside polyline.
I will try something and post it soon…
@RadovanG that means one thing that theres no point to believe gh profiler in terms of watching time for c# code indeed i didnt pushed any of solutions to VS. Did you tried other solutions as well? I just ask if not ill test them as plugs cause differences are really huge.
Gh profiler is OK, but gh is slower because of data manipulation.
I will clean up the code an post it shortly.
Code is based on curve conversion to polyline and applying algorithm like ray-shoting.
R
@RadovanG i also wanted to ask is there any particular reason for checking points in circles? Aren’t bboxes better in this case? They should contain smaller amount of points than circles.
Because constructing such a circle is fast, while constructing boundingbox for curve is slower.
But new solution I have is not using another approach - code will be posted in few minutes.
And the winner is … @RadovanG ! Outstanding performance man ! I really appreciate your help guys! I received more than i would expect Thank you @RadovanG@qythium@RIL@DavidRutten for your input, help and involvement in this topic!
By any chance, do you know if it’s possible for this code to output seperately the indeces of the points that are NOT contained in the curves as well?
All in all, there will be two outputs for the C# component. One is the indeces of the points that ARE contained and the other output are the indeces of the points that are NOT contained.
Thanks for the suggestion! But I don’t really need the points outside of the curve boundaries. What I actually need to get from this is really the indeces of those non-contained points themselves.
The reason for this is because I’m planning to re-create the data structure that I have that was lost when ran through this C# component. Even though it does run very fast, it outputs a flattened list of contained points which is not very useful for me since, in my case, the data structure is needed to be kept.
What I’m planning to do is re-create my data structure by matching a list of booleans (True for the indeces of the contained points and False for the indeces of the uncontained points) with that of the original dataset’s. After that, I would dispatch my original dataset and retain my original data structure.
Thanks for the idea though! I think we can do something similar by creating a series of numbers that matches thr length of my original dataset and use the indeces we got from the C# component and cull them out. I’ll try this out first thing tomorrow and update this thread if it’s fast enough. The calculation speed is important for me here so that’s why I preferred the C# component to do the job if possible.
Thank you 
