Patch component bug?

Hi McNeel,

please have a look at the attached GH definition with a patch component example. Depending on the number of spans, the patch component fails with a “…reference not set…” exception.
At 10 spans: Successfully patches all curves
At 20 spans: Around half the curves get patched successfully
At 40 spans: None of the curves gets patched (40.9 KB)

Looks like a bug to me?
Thanks for looking into it.

Anybody? Just want to bump this up. Thanks

To debug, go up step by step:
First, using a default Patch use just one point and one curve

Then introduce a fix spans number and later flexibility.

Then select 2 curves and assign it to the curve input.

Is what you was expecting?

  • Yes, then go on and increasing the number of curves and points.
  • No, why? Explore the manual. It can be a Flat problem in the output or input? (I never used the Patch tool)

I’m not an expert but inpecting the values using the Panel,

using {0} containing the reference points works
and you are using {0}{1}{2}
Probably you need to place all in {0}?

Thanks for giving it a shot Alan!

The issue is not the GH end for me, but that the code behind the patch component seems buggy. I am posting this for McNeel to get notified about it. Usually they put such things on their bugtracker, but somehow this one got overlooked.

Thanks again.

1 Like

BTW: See what span means and never put excesive stress (that has no real-life meaning) in things. (152.7 KB)

Since you are using points as well: spot the flexibility effect in D (face dist to p).

That said patch has certain issues but if you use rational values … it delivers the goods in most of times. That said treating patch via C# (in 2 phases) can expose various failure reaons (if a failure occurs).