Some Lofts Fail and Some Lofts Work - Why?

I have a series of concentric, star shaped polylines and have moved them twice in Z, offsetting the middle set, and want to create a loft between the sets of 3 polylines.

I originally did this with a scaled star shape as the middle set and it worked but isn’t quite what I’m after.

Some of the lofts work - use the List item component to select individual lofts and you can see that items 2 and 10 are what I’m after…

The other lofts seem to have the middle curve flipped. Why does this happen?

I think I can fix it using flip curve with a guide curve [EDIT: No I can’t!], but why does it happen when I use an offset curve as the middle set and not a scaled curve? Is it a bug or something to do with offsets? (30.4 KB)

If I swap out the Offset and manually move the polyline vertices outwards, then reconstruct a polyline, it works in this example, but when I do this in my main definition, it fails on some of the Lofts. (31.1 KB)

Is this a bug?


Why do that? There are other ways to resolve data tree differences.

If you delete the Loft Opt component it works well, except for the smallest curve that needs to have its seam tweaked. (28.0 KB)

Like this: (35.8 KB)

Renumber Paths works for me but I try and avoid using it unless its towards the end of the definition.

How would you resolve the tree path differences in this case, out of interest?

Removing Loft Options…
It’s still not consistent though. I found a solution that doesn’t use Offset but I’m just puzzled by the odd behaviour of Loft… why does it work on some sets of curves but not others?

Thanks for the reply

Look at both files I posted.

Topology of the polyline changed after offsetting outward.
Honeycam 2024-04-07 21-27-11

1 Like

OddLoft Edited v0 Parakeet .gh (34.1 KB)
So, just align them. Parakeet.

1 Like

Does it do something different on your PC?
I’m using Rhino8 and gives this… gives me this…

Good tip on Suirify… never even noticed that component before. I wonder if it snuck in after Tree Sloth became a thing. I’ve used Tree Sloth for years.

That’s weird behaviour though, right?
A negative offset doesn’t change the topology but a positive offset does.

Seems like a regression.
Tested in R7. No issue. Not sure if Mcneal care about GH bugs in R8.

If Mcneal cares about GH regressions in R8, please also care about these, thanks.

Again, Extrude - Grasshopper - McNeel Forum

[BUG] Boundary Surfaces output wrong sequence - Grasshopper - McNeel Forum


Well hopefully they do… it’s going to be really annoying if old definitions don’t work and we have to find work arounds for behaviour that didn’t exist in R7.

I normally can’t afford to upgrade and wait for ages; usually just before R(n+1) is released I upgrade to R(n) and don’t have any issues. Perhaps it is better to wait until all the bugs have been ironed out before upgrading.

1 Like looks the same for me in R8. Most buggy version of GH I’ve ever seen :bangbang: also looks the same for me in R8. Seam is emitting “Invalid Curves”. :frowning:

U can use the Component "Offset Curve Loose” before this will we patched. There u will not have this Numbering Problem. Maybe it can help u for the moment.

1 Like