Bug: MatchSrf Fails to Maintain Isocurve Direction (CP Flow)

MatchSrf needs some love:

MatchSrf_IsoTest.3dm (1.6 MB)

-Sky

1 Like

Hi Sky - isocurve direction is being maintained, but I do not think MatchSrf should do anything at all in this case - that is the bug.

-Pascal

I disagree - If you dup the edge and then run Match to the base surface, that to me is the edge that MatchSrf should be holding - MatchSrf is reading the edge as if it is degree 1, when it’s not:

Maintaining isocurve direction is just that - direction, not shape or curvature. The idea is that the points in the second row of control points keep their relationship to the points edge in the row as much as possible - that vector should stay put, for each pair of points (edge point, second point) on the surface being changed. - it does not have anyting to do with the third row at all.

-Pascal

Here’s the behavior in VSR, in the most default settings (correct behavior):

Can we get Rhino’s MatchSrf to behave in the same way?

I think there’s two things going on here - 1 this is a simple case that should not be failing but is.
2 - Maintain Isocurve Direction in MatchSrf very often produces bad results. You may or may not think that this case is illustrative of that, although I do.

2 Likes

Well… I think MatchSrf should do nothing here.
RH-2334 MatchSrf: The surface is still changed and shouldn’t be

Maintaining the shape of the input surface is on the list of things to improve, for sure,
RH-58712 MatchSrf : maintain the control point flow

but in a case like this it should not even come up at all- the inputs being perfectly matched to begin with. However, none of that has anything to do with maintaining isocurve direction - I do not see any change in isocurve direction with the matched surface here.,Maybe this will illustrate what it is doing, maintaining isocurve direction:

The arrows are continuations of both the starting and ending isos. The tangent points have not moved.

-Pascal

I understand what you’re saying, I think we disagree on whether MatchSrf is doing things that are sensible and useful.

1 Like

Another example showing the bug/undesireable behavior:

SimpleTestCase.3dm (3.0 MB)

3 Likes

Third example:

ManualMatching.3dm (2.2 MB)

Do you see how in all these cases, I’m asking MatchSrf to do something easy, logical and useful, and in all three cases MatchSrf is doing things with the third row of points that creates an undesirable result?

3 Likes

Hi Sky - there are a lot of things that could be better about MatchSrf - the two bug items I listed above adress two of them, the ones I think that are underlying all of these examples - but you’re moving the goalposts here - I have not seen any evidence so far that the ‘preserve isocurve direction setting’ is doing anything but that…

-Pascal

Can you repost the link to -2334? It’s not working for me.

Yep, try now… I made it public.

-Pascal

Good lord that bug report is 10 years old.

1 Like

_MatchSrf has the Preserve other end selection, but it would also be useful to be able to individually preserve the other two sides’ continuities. It seems that this functionality would be helpful in your 2nd and 3rd examples.

Really the gist here is that MatchSrf needs to have the option to constrain each vert in UV and only move them in N in order to match. Also, this bug should have been fixed around 10 years ago.

8 Likes

I’ve adjusted the title of this post (CP Flow) and added it to the mentioned YT

3 Likes

Thanks Gijs!

@sgreenawalt I’ve also noticed this behaviour with curvature matching; the perpendicular edges come off the expected positions. I often see myself going back and matching those edges back for position… which shouldn’t need to happen.

1 Like

This particular huge issue has been discussed many times over the years… Just a couple of examples:

2 Likes

It’s a ten year old bug after all, and I’ve yet to see any enthusiasm on the part of McNeel of addressing it.

4 Likes