MatchSrf needs some love:
MatchSrf_IsoTest.3dm (1.6 MB)
-Sky
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
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