No, it appeared to be contoured terrain. I don’t think it slowed down the knot-related code but it made the GH file 6.1 MB instead of only 9.8 KB for the same file without it (celtic_pattern_clean.gh).
Do you think it’ll be possible to use your technique and have the repeating pattern connect between the sections?
It seems all of the solutions require a join so it’s a contiuous curve, except yours. I’ll try to find a way
Ah shit yes. I remember. I was trying out the curve selector definition on someone’s terrain from the forum! oops
You can unroll the ring surface and use it to fix the start and the end
Does this depend on a closed curve? I connected only one end of the two curves and waited 56 minutes(!) for your C# code to finish and produce this:
P.S. Looking at your offset curves, I see some overlap that could be a problem?
I’ll extend both lines slightly to avoid that and try again.
OK thanks
Ugh, 56 minutes. I’m sorry Joseph! And tell I’m sorry also to your CPU…
Yes, I guess that definition require a closed curve and a proper start/end seam position.
Also those unwanted overlaps, yes, better if they don’t happen.
Another way: (still requiring closed curve, seam position fixed with a point, beware)
celtic knotwork V2.gh (34.9 KB)
Once you shatter each curve, we can just keep the segments correct segments with a simple pattern… works with this specific style, don’t know if can be applied to others…
Still waiting for the re-try to finish. I gave it a closed curve this time but didn’t pay attention to start/end position (seam). Is that important? I haven’t tried to understand how it works but find it interesting that @inno’s solution using standard components is considerably faster than your C# solution.
With no sign of progress, it’s difficult to be patient and just wait. There must be a faster way?
Perhaps I’ll get around to trying some of the code in the thread @laurent_delrieu mentioned.
Still waiting…
P.S. It finally finished. 59 minutes for the C# component, but it looks good (except for the closed ends which will have to be chopped).
celtic knotwork_2022Oct2a.gh (27.4 KB) (slow C# disabled)
P.P.S. It looks like the best way to get speed on this is to do one section and then repeat it.
OH! This V2 is WAY FASTER, and no C#? First prize!!
Looks like some of the surfaces are flipped.
P.S. As you know, flipped surfaces are easily fixed by flipping curves with a circle as guide:
The part with shatter + culling was slow… thousand of numbers and thousand of curve objects jumping around from component to component…
I were wondering if keeping everything inside a c# script would have been faster… it is.
(the 2 c# script have little difference for the different patterns…)
celtic knotwork V3.1.gh (31.1 KB) (fixed Curve<>NurbsCurve parametrization vaguity)
The algorithm is almost the same as the V2… but the part of shattering (or better, extracting sub-curves now) is 10x faster now.
The slow part is the offset…
Maintaning this kind of code is not really good though… no idea how it behave with different starting curve
yeah… combine some grasshopper work with some other manual work in rhino… always the best!
…but we are stubborn and want to do everything with grasshopper!
Still playing with your V2, I’ll try V3 soon. Still haven’t tried to figure out how it works.
For a fair benchmark comparison, I applied your V2 to the longer original curve, which has 40 copies of the pattern instead of only 16 copies in your example. I adjusted the ‘Half-width’ and ‘gap’ sliders accordingly. Still, it took only ~3 minutes to complete vs. 59 minutes for the C# version. Impressive!
celtic knotwork V2_2022Oct2a.gh (40.9 KB)
Now for your V3…
WOW!!! Super fast, only a few seconds. Amazing. I won’t even try to understand the C#.
celtic knotwork V3_2022Oct2a.gh (33.9 KB)
Well done Riccardo.
Khaled’s first solution is still a bit faster than mine.
knotwork_V2.gh (19.6 KB)
(I’ve edited to use a single closed curve and made Fennec equivalents in c#…)
The starting offsets (expensive tasks as it is a long big curve) are half amount than in my solution, and later each small region is made again an offset (probably cheap because many small curves > multithread helps here).
Smart use of region logic!
I’ve been using the pattern from @gileshg’s second post (40 repeats) while everyone else seems to be using his first post (16 repeats)… Which one is correct?
For Khaled’s solutions is “celtic_pattern_boundary_only.3dm” from second post…
The GH file in @gileshg’s second post, celtic_pattern.gh (6.1 MB), shows the pattern repeated 40 times, not 16 times. knotwork_V2.gh doesn’t use the Rhino file.
Too much work, I give up.
I mean… to me, Khaled’s .gh files works with celtic_pattern_boundary_only.3dm from second post…
You need Fennec plugin though… (or use c# equivalent from my last .gh)
Maybe i’m talking about something unrelated from what you asked… … 01:30 am here…
Sorry about the different iterations and lack of consistency! I have been chopping and changing methods and trying to keep them in one doc. The number of repeats was a parameter to help me get the pattern to meet at the right scale for various sized rings. The circumference/target line on the ring is meant to be linked up to the base curve for the flowed geometry. I think I managed to get that to help. In any case, this is why some had many more repeats than others.
Looks nice with a little rhino merge surfaces on the joins!
Love it. Do you think if the ends of the offsets were joined (like a cap image D) then the ends of the regions would form like the rest of the knot?
celtic_ring2_definition.gh (6.2 MB)