Posting this under Grasshopper but this may be a Rhinocommon bug.
I have a strange behavior with the seam component. I am adjusting the seam of a curve based on the t parameter output of Curve Closest Point, using a reference point.
The reference point I’m using has a projected t parameter equals to 0 (at least a displayed value of 0).
In the attached GH file, you will see that the Seam component adjusts the seam to ≈ 0.02762 (relative to the original curve).
If instead I use a hard-coded value of 0 for the t parameter, I get an adjusted seam at t=1 (which sounds fine for a reparameterized curve).
Is it a bug or some very tricky edge condition due to the value of the computed t not being exactly equal to 0 (due to floating point rounding errors)? It doesn’t sound right in any case, as the new seam is quite far from the target.
NB: I know there is no point in setting the seam to the exact same location as the original one, but this was one of many curves I had to fix in a 3D print (layers). In this case I need something that works for all layer curves, regardless if the seams has to be adjusted or not.
Thanks, but it has repeated control point because it is a periodic NURBS curve. This is expected, there’s nothing wrong here.
If you look for the the Control Points of the NURBS curve you have reconstructed, you will see it has the exact same structure as the original curve (31 control points).
It works because after you have rebuilt the curve, the seam point is no longer at the location of my reference point.
In my testing I found the bug happens only when the reference point is exactly on the existing curve seam, i.e. when Curve Closest Point returns t = 0.
In fact, I’m not asking how to adjust a seam interactively via Grasshopper. I was pointing out a very strange behavior in the seam component, which sounds like a bug.
We have a bunch of curves that compose layers of a 3D print. The seam is correct for all curves except the last one. This happens often when I receive files from students. In a real case scenario there may be more than one point to adjust, but in most cases most curves will have correct seams.
In the file, I have baked the original seam points and manually adjusted the location of the last point, to provide a target for seam adjustment. I didn’t change the location of the points that are already correct.
You will see that the computed t parameter value for these correct points (0) cause the seams of the corresponding curves to shift. They should not be moving.
What’s even stranger is that, if you add 1 to all computed t parameter values, this solves the issue.
This means I have found effectively a workaround for my use case, but that doesn’t explain the behavior I get without it, and I feel this is an issue worth reporting.
Rather than maintaining two separate lists (curves and points) and hope the orders are correct, its probably best to base closest point computations some known curve that represents where you want the seams of the curves to be.
In this case, I just took your points and created a reference curve through them. Then compute the closes point of each curve to that reference curve.
You can see by the results, only one curve was modified.
Also, I’m not a fan of reparametrizing curves; I have no idea why people do this. It is so not necessary in this case.
Yes, but, as I think you have checked, the orders of the two lists in my definition do match. I have pre-sorted the curves and the points (which is trivial to do in this case, and will always be in my application). So I don’t think this is relevant to the issue discussed here.
This approach would fail if one had to use a more complex data structure with separate tree branches for print layers, as is required in some instances. But that’s a different discussion.
In any case, I hope we can agree that changing how you compute the t parameter value you feed into the Seam component should not impact the behavior, provided the computed value is correct.
I agree that changing how you compute t seems to solve the issue in your file, but I have no way of understanding this rationally.
By the way, the Seam component throws a 1. Curve seam adjustment failed for unknown reasons warning in your definition, which doesn’t feel right either.
This should be a matter of personal preference. But can we agree that reparameterizing curves should not change the result of operations like seam adjustment?
The issue is, it does: if you reparameterize the curves in your definition, you get the same issue I had :
