I have a surface built from four curves using EdgeSrf: [image] I then use MatchEdge on the left and right side with the following settings: [image] What now happens is that the bottom edge of the surface lifts away from the ground plane: [Skärmbild 2023-02-07 163140] The U-direction of the left hand matching surface should all be perfectly horisontal so why does this happen? What did I miss, or what’s the math/underlying theory that causes this? I thought if I have my CVs in order, match results would be predictable. G2.3dm (161.6 KB)

Hello- your target surface has curvature in both directions - [image] Also, you have ‘Preserve Isocurve Direction’ set. Hm - it is true that ExtendSrf keeps the extension in that plane though… -Pascal

I assume by “ground plane” you mean the x=0 plane. Can you post a file which includes the surface before MatchSrf? A guess is the result you did not expect may be due to using “Preserve isocurve direction”.

As mentioned, the original surface was built using the four encompassing curves and EdgeSrf. I’m more interested to learn if there are better ways to build the surface in this instance! Your other assumptions are correct.

[image] Pascal Golay: your target surface has curvature in both directions Trying to understand the algorithm’s behavior here, why would this be significant? As you noticed I have “preserve direction” on, which should mean only normal direction adjustment, and as you saw with ExtendSrf, the U direction is completely horizontal at that bottom edge, so where does the slight elevation in the match result come from? If I purge the history and match with “target direction”, the elevation is still there.

This looks like the same issue: https://mcneel.myjetbrains.com/youtrack/issue/RH-35431/Class-A-wish-Blend-surface-with-G2-on-edges (MatchSrf is mentioned in it, but I didn’t find its own issue.) My understanding is that the locations of the 3rd row of control points from the edge are set to achieve surface G2 continuity, which is not necessarily isocurve G2 continuity. For the latter, MatchSrf should have Isocurve continuity adjustment instead of Isocurve direction adjustment, where the order of continuity is the same as that of the surface matching.

@eobet - the developer has had a look, and thinks this is an error - no reason for that point to be ‘off the ground’. -Pascal

Thanks for having a look! Full disclosure: Both Siemens NX and Autodesk Alias produce the same result, however only in Alias so far have I found an option to keep it on the ground (called “colinear”). So, it’s perhaps something fundamental with the math which is “technically correct”, but from the outside looking in it still appears odd and seemingly unpredictable… and predictability in a tool allows you to work faster with it, so that’s why I’m trying ot understand this.

Help me understand a basic G2 matching question

Rhino

Lagom October 16, 2026, 10:13pm 9

Unfortunately, an old bug, waiting to be resolved - the Preserve isocurve direction option does not necessarily preserve the isocurve direction like in Alias or Catia.

Topic		Replies	Views
Why did MatchSrf change and already G2 surfce this much? Rhino for Windows	2	721	July 6, 2020
Should "Match surface" behave this way? Serengeti (Rhino BETA) windows	12	769	November 3, 2023
G2 matching problem Rhino mac	5	209	August 26, 2025
Bug: MatchSrf Fails to Maintain Isocurve Direction (CP Flow) Rhino for Windows windows	29	1629	September 30, 2026
Surface Matching? Rhino windows	16	1015	June 20, 2023

Help me understand a basic G2 matching question

Related topics