I am trying to get a part of a curve that is bounded by 2 points on a curve.
From the picture above, I have a point at one end always touching the vertices of the regular polygon and one near the middle of the curve, and I tried using pufferfish’s Points Trim Curve function, and sometimes it gives the correct segment of curve, the part not between the points, but sometimes it gives the part of the curve between the points? Is there an elegant solution to this?
The picture above is my end goal. I am trying to get the green curves and remove the yellow curves and wrap that all around the regular polygon.
dome.gh (21.1 KB)
Thank you for your help
Catenary curves again, eh? Why Python components for simple math? And why extend the lines? More complex than necessary, I think.
I added the white group and left the code before it alone. The cyan group has pairs of curves for each section.
I am currently doing a project around designing compression structures, therefore catenary’s. I would love to know how to make the structure simpler.
The picture of the dome on the left is exactly the shape I want, but when I open your code I only get half of the dome, even though I haven’t changed anything. I am using Rhino 7.
Strange. Are you on a Mac?
How about this? I replaced List Item with the purple group to get the segment closest to each vertex of the polygon instead of assuming it’s always first in the list from Shatter.
Hasty, not quite awake yet…
P.S. By the way, here’s what it looks like using the segmented polylines from Catenary instead of converting them to interpolated curves:
I am on windows 11. My Rhino version is Version 7 SR11 (7.11.21293.9001, 2021-10-20) and below is a picture of my grasshopper version if it helps.
The solution you sent nearly works, there are only 2 faces that are inverted for me.
The same happens with the polyline version.
I can see what’s going on but am not sure yet how to fix it.
WEIRD! Win11 is not yet ready for prime time!!
P.S. How about if you enable ‘Align sections’ in loft options?
It works! Thank you very much! Can you explain what you did to the loft?
‘Align sections’ tries to make sure that curves have the same direction (start/end points). The question I have is why these extra steps are needed at all for Win11? Maybe later, after coffee.
This numbers the vertices of the catenary curves. They should all start with zero at each vertex of the polygon, as shown. Does it work that way for you on Win11? I suspect not, but don’t know why?
It seems to switch halfway through for me, interesting.
Yes, interesting. Maybe someone at McNeel should look at this, because as Win11 becomes more common, there will be similar issues causing trouble for others. Thanks.
Today’s version ‘a’ (below) tries a different way to isolate the peculiar Win11 results. White points should be at the start of catenary curves (at each vertex of the polygon), blue points at the end.
Version ‘b’ uses a different way to get the start/end points. If this looks correct for you, then maybe version ‘c’ will also work?
Version ‘c’ reverts to the original, simpler version of the white group while using version ‘b’ endpoints…
Yo, I just discovered a problem that has been in this code all along, since my first reply two days ago. Here is what I did that gave me my first clue:
See it? I expected a single “Closed Brep” from joining all the sections and using Cap Holes but there is an extra “Untrimmed Surface” here…? I used my ‘Tree/List Viewer’ tool to see the unwanted “surface” and realized it was only a line, probably a result of trying to loft identical curves.
But it turned out to be a little trickier than I expected to investigate further because when Area is connected to Loft, Rhino hangs very hard! I had to use Task Manager to kill Rhino.
To make a long story short, I had to replace this:
dome_2023Jun5d.gh (25.6 KB)
Explode returns one duplicated point whereas Discontinuity (Disc) returns the correct number, one point for each vertex of the polygon. I have known this for years but missed it until now. Oops.
I don’t think this explains the Win11 anomaly but…
Sorry for the late reply, I was only free until now.
Version 5a seems to work, it shows the exact same as the picture you sent.
Same with version 5b
But weirdly enough, version 5c doesn’t show up correctly?
Also 5d does not work too, if you wanted to know.
Wow, I guess that isolates the Catenary component as responsible for the Win11 anomaly because versions ‘5a’ and ‘5b’ prove that it is being given the correct start/end points.
@wim, we have apparently found a Windows 11 anomaly in the R7 Catenary component.
That’s no surprise because 5c and 5d both use the white group from two days ago, Jun3a, before changes were made to circumvent the Win11 anomalies in version dome_2023Jun4c.gh (the marked “Solution” with purple group and ‘Align sections’ in loft options).
To summarize, today’s version ‘5d’ is the most correct, but it fails for mysterious reasons on Win11. The Catenary component appears to be at fault since we proved its inputs are correct (5a and 5b). Version 5d can be “fixed” to work on Win11 by replacing the white group with the 4c white group that has the purple group (kludge) and ‘Align sections’ enabled in loft options, but that should not be necessary.
@Japhy ? @wim ? Cleanup needed for R7 GH Catenary on Win11.
P.S. To clarify further, what appears to happen here is that 15 catenary curves are created, one starting at each vertex point of a polygon, yet roughly half of them have their start/end points reversed on Win11, as if the curves have been flipped.
I have encapsulated a fix to the Windows 11 catenary bug identified above, in a CatWin11 cluster (yellow group). @Thomas_Chu1, can you please test this on Win11 and confirm it works?
The cluster compares the start point of catenary curves with the ‘A’ input to Catenary. If they are not the same, a flipped catenary curve is used instead.
Hopefully, McNeel will fix this bug soon so others won’t struggle with the issue as we did in this thread.
It works perfect this time! Thank you
sorry for the late response @Joseph_Oster @Thomas_Chu1 but I cannot seem to repeat the issue here on Win11. What’s the _SystemInfo on the machine that fails to display this correctly?
So version dome_2023Jun5d.gh above works for you on Win11?
I don’t have Win11 but squandered considerable time and effort dealing with the flaw reported by @Thomas_Chu1 in the Catenary component.