MatchSrf strange behaviour

[Gib_Son]

Can someone please explain this weird behaviour?

When I match the red surface to the green, the curvature control points cross on the red surface. This should not happen. Why is MatchSrf behaving like this? This does not happen in all other 3d softwares, actually before performing the MatchSrf, the surfaces are actually G2. It s changing them, and changing also in a bad way. Thank you.

Here is the rhino file

rhinoMATCH.3dm (236.4 KB)

[davidcockey]

Bizarre. The two surfaces are simple, non-rational degree 5x5 single span surfaces. Nothing peculiar. Before MatchSrf the surfaces are exactly G2 but after MatchSrf they result is no longer G2. I reproduced the same in V9 Beta.

The two surfaces are simple, non-rational degree 5x5 single span surfaces. Nothing peculiar.

Seems like a high priority to be looked at and fixed.

[Gib_Son]

Yes David

There seems to be a bug with Matchsurf everytime when aligning for G2, it does not happen for G1. Rhino always moves CVs in the 2nd row, even when explicitly told to preserve isocurve direction, and with the other options it messes up that 2nd row. We are on V8, and this still persists?

This alone, makes it basically impossible to use this software for me, anyway, it s such a basic and important feature… I don t understand…I model with 1 span surfaces, like in Alias and Icem.

This issue should be seriously looked into for the new V9 coming. I love using Rhino, but this issue just makes it impossible for me. I tried every single fix I could think of, like, making sure CV weights are 1, reparameterizing surfaces from 0 to 1, Makeuniform, etc etc…Haven t been able to fix a good CV structure when using Matchsrf, as it is super important for 1 span surface modeling, it s all about the flow of CVs. Also using history on the actual surface that is being aligned to another one, doesn t enable to move CVs as it should. Only allows on the other. This should also be improved.

Thank you very much for your input…Any other Matchsrf Script that fixes this issue and actually works as expected?

Looking forward to hearing from anyone who can have a fix for this.

Thank you all

[skysurfer]

I’m getting the same lot of time, and is annoying.
Maybe @Gijs has workaround, usggestion or bugtracker for this,

[Gib_Son]

This makes it impossible for me to model with good surfacing practices.

I just can t use it as it is. This should be easy to fix, the maths is wrong.

I m surprised V9 still has this behaviour…How can someone model with such basic issue?

I m really frustrated, I like everything else in Rhino. Sorry

[Gib_Son]

Thank you my friend for your suggestion

[Rhino_Bulgaria (Bobi)]

This is a well known limitation/bug of the “Match surface” tool. Rhino fails to match G2 by the normal direction only, resulting in a highly distorted 3rd row of control points.

Check the first request in this topic:

Rhino urgently needs these tools!

Currently, Rhino is in something like a NURBS-crisis. Alias made a huge progress in the past 20 years, unlike Rhino’s main NURBS surfacing and control point editing tools that are nearly unchanged since Rhino 2 (with a few minor exceptions). The last few versions of Rhino focused more on non-NURBS stuff, such like tools for Sub-D, 3d meshes, ShrinkWrap etc. While these are nice additions, the NURBS tools are left in the corner. Both, “Blend surface” and “Match surface” lack a huge amount of fun…

Also discussed here and in several other topics about a decade ago:

Wish: "Match surface" to preserve the flow of control points

I wondered if the “Match surface” command could be upgraded to apply G1 or G2 to the general shape of a surface, while preserving the flow of its control points. The current implementation with curvature match (G2) forces the 3rd row of control points to follow the direction of the 2nd row. However, in many situations this will destroy the ideal shape of a surface. For example, Alias could apply curvature match that only adjusts the control points of the matched surface only in the normal direct…

[Gib_Son]

Thank you Bobi

It s dificult to believe that such a basic thing is actually true.

Well, no more Rhino for me then. I don t like Plasticity also. It s crap .

It s only good for surfacing uneducated people

[Rhino_Bulgaria (Bobi)]

It’s fairly easy to fix that manually to some extent if you aim for a G2 deviation of about 0,01 (good enough for general product design other than cars for manufacturing) by manual point adjustment via Gumball for a minute or so, but it takes a lot more time to reduce the G2 deviation to less than 0,005.

This video shows an example of how to reduce the G2 deviation. My first attempt before the video recording was quicker and I achieved 0,001 maximum deviation, but then the recorded attempt got much worse as I didn’t do the adjustments properly. Still, even at 0,01 the G2 deviation is visually smooth for most purposes. I call this G1,9 for obvious reasons…

This decades old bug is still not fixed in Rhino 9

Another bug shown in this video is graphical. The latest build of Rhino 9 Beta will ignore the object colour and will only switch to the proper coloured object rendering mode when the control points are turned on. This particular bug was introduced recently, so my hope is that the developers could figure out what causes it easily and fix it in the next build of Rhino 9 Beta.

[spb (Steven Burzinski)]

Possibly related:

1. Create a surface from the red surface with
   _ExtendSrf _Type=Smooth _Merge=No
   (Blue surfaces in images below.)
2. _BlendSrf between the new surface and the green surface with a continuity of Curvature or higher.

The result has a crisscrossed control point pattern for the middle 2 rows. Even at the Tangency continuity, the control point pattern already shows a tendency toward crisscrossing.

BlendSrf_me.3dm (71.2 KB)

[menno (Menno Deij - van Rijswijk)]

I have created this YouTrack ticket for this issue: https://mcneel.myjetbrains.com/youtrack/issue/RH-96771

[Rhino_Bulgaria (Bobi)]

This is the 3d model used in my video above. The initial version was way better, with up to 0,001 G2 deviation, but I don’t have the free time to reduce it further. If you apply “Match surface” with G2 to it, Rhino destroys the surface again as in the OP’s sample.

rhinoMATCH Bobi.3dm (467.1 KB)

[Gib_Son]

Thank you everybody for being so kind and helpful

[Lagom]

Definitely not acceptable for a NURBS modelling software in 2026.

[Rhino_Bulgaria (Bobi)]

The sad truth is that we may not see a “Natural flow” option for the “Match surface” tool even in Rhino 10… That request is very old and multiple people asked for it during the years.