Trying to fit curves to a region without using Trim Region

[Raam]

Hi folks,
I have a very large file where I create around 100,000 lines inside dozens of closed curves of various shapes. Here’s a picture showing what I mean:

I’ve been using Trim Region for this to date: I create a bunch of lines, place them over the region (the closed curve) and then use Trim Region. The problem is this is quite slow for the number of lines I’m trimming, and every little adjustment to the script results in waiting minutes for it to calculate, so I’ve been trying to find an alternate way to do this, and have had some success with Contour, which appears to be much faster than Trim Region.

I have an additional complication now where rather than simple lines, I need to fill every region with a series of ‘stripes’ which individually form closed shapes (as pictured above). The stripes need to be a consistent width and distance apart that I specify.

I’m running into a couple issues with the Contour approach. One of which is that when I adjust the stripe width or distance, often the points at some extreme of the shape move off the shape and disappear, which means the next line is now the first point, which causes the closed and open sections to invert. Here’s a GIF showing what I mean:

How can I fix this? Is there a completely different approach to what I’m trying to do other than Contour or Trim Region?

Another thing that would be nice to figure out is how to close the appropriate lines with a section from the region they’re inside, rather than a straight line between them, as this sometimes causes corners and tight angles to be lost (as shown here):

I’ve attached the grasshopper file here. Region stripe fill.gh (22.4 KB)

Any thoughts appreciated,
Thanks

[HS_Kim]

This could be a way but, It won’t reduce your calculation time when if you deal with 100,000 lines at once…

Region stripe fill_re.gh (27.6 KB)

[Raam]

Unfortunately the Region Intersect seems to be even slower than Trim Region so is a nonstarter.

[Raam]

Yeah, it’s about 800% slower:

[HS_Kim]

@Raam

Another thing that would be nice to figure out is how to close the appropriate lines with a section from the region they’re inside, rather than a straight line between them, as this sometimes causes corners and tight angles to be lost (as shown here):

Of course it’s slower. I just fix that issue you mentioned…

[Raam]

Just realized that - it’s a great solution - thank you!

[PeterFotiadis (Pfotiad0)]

@Raam

800% slower

Curve bool ops (most notably with curvy stuff) are indeed slow. That said I have a C# that does that kind of stuff (the analytic way using recursion on Curve bool Methods - intersection for a given stripe VS the outerLoop and then difference VS the inner Loops (if present)). But … results timewise range from pathetic to unacceptable. See linear VS curvy test data (with or without inner Loops):

If on the other hand 150 ms (for the topology shown - more or less) is not that pathetic for you notify.

[Raam]

Honestly have no idea how to tell if it’s faster or slower without testing it - which I’d love to do. Would you mind posting your module?

[PeterFotiadis (Pfotiad0)]

OK, added a few things more and here comes the pain (slower than any Harley Davidson):

BrepFace_Stripes_V1.gh (133.5 KB)

In fact (other than the recursive Method used for the Inner Loops (BrepFace holes so to speak) - i.e. not using the Curve.CreateBooleanDifference (Curve, IEnumerable (Curves))) this is a parallel tutorial for my people in the practice.

But I can’t post the real McCoy since any pragmatic // thingy is strictly internal - for obvious reasons. That said a proper thread safe // implementation on a 16/32 core I9 K could turn the unacceptable part into … er … a pathetic one.

For big N of Faces you’ll need CUDA computing.

BTW: If you by-pass recursion with the orthodox Rhino Method as mentioned above … you’ll get bananas.

[camelworks]

you can try centering the big file so there no extra large numbers.
I think the distance from the 0 0 0 matters. you could put all the shape on top of each other, make that part of the operation than spread them.