When I use the “OnSurface” option of the “Match surface” command, quite it would produce some inconsistent and twisted results. To reduce/eliminate these unwanted results, I suggest to force Rhino to match strictly onto the target surface. Check this sample file. It consists pretty simple surfaces, yet “Match surface” gets confused and twists the matched surface edge in a strange fashion.
Here is another example using the same target surface, but this time the target curve is split into two halves. “Match surface” produces strange results while using the “Refine match” or “Match edges by closest points” options.
Hi Bobi - matching by closest points will get you the second result - that is what it is meant to do, but I do not, so far, get the anomaly you show in the first image - it looks clean here - am I doing something different?
Hi @pascal , the issue comes from the inability of “Match edges by closest point” to distribute the matched edge in a proportionally correct way. Instead, using “Match surface by closest point” will try to fit nearly half of the control points into a single spot. You can clearly see that if you also activate the “Refine match” option. Check here the updated file where I added a red curve next to the blue one. This is how “Match surface by closest point” should behave even if the blue curve is being used. The current implementation of “Match surface by closest point” has many weaknesses and my example is just one of the many cases where I had issues with it. It’s a nice option, because it lets the user match a surface edge to a limited area instead of matching to the entire length of the target curve or edge. It just needs some fine tuning to make it more reliable.
I also would love to see a major improvement in “Match surface” by adding the ability to manually slide the end of the matched edge along the target curve or edge. This should be done in the same interactive way like the one already used by “Blend surface”. Maybe you could copy the code for this particular functionality from there and use it in “Match surface”, too. That will heavily reduce the time for experimenting with different target curves on surface (as the green and blue curves in this sample file) and will also eliminate the need to preliminary split the target edge, which brings other negatives to the model that affect its *usability.
Speaking of the latter, not sure if the development team have noticed, but splitting a surface edge and then merging it back to its original form produces a totally different edge properties! This is easier to notice while using “Blend surface”, but the issue affects other commands, too. This is why it would be a huge relief to be able to slide the end of a matched surface interactively rather than relying on a split target edge. Here is an example that shows the increased complexity of a surface edge that was first split and then merged. Rhino fails to revert the split edge to its original simplified structure consisting just 4 control points, hence “Blend surface” goes crazy and produces a surface with 24 control points instead. Rhino must be smart enough to detect if a border edge (not one inside the surface) have been split, so that when the “Merge edge” command is applied to it it will go back to its original simple state. Alias already does that and this is how it’s able to achieve clean modeling.
Of course, your team may not consider this a bug, but from a modeling perspective, this is really an unwanted behaviour, because it brings a whole lot of issues with added complexity that should not exist. This is why splitting an edge just to match another surface to it and then merging it again has its negatives with the current implementation. Also, splitting an edge this way breacks the history of connected objects and even destroys their intended shape (as seen at the 1:33 minute of the video upon using “Untrim”).
Hi Bobi - Yes, of course, but why would the ‘closest points’ setting do that? That is exactly what it does not do…
Anyway, yes indeed, MatchSrf can use some improvements, no argument there.
Would thinking and taking as a reference a “match surface” like the fairly functional one of VSR be an unhealthy idea? The same should be for the “blend surface”: it has been retouched for years, but we are still far from tools like VSR and icem surf.
Difficult? Impossibile?
Will we have to wait for Rhino 20?
As I mentioned above, the main issue is that “Match surface by closest point” does not distribute the edge to be matched in a proportional way. Instead, it will try to match a certain portion of the surface to be match to the target edge or curve on edge, while other portion of the surface will try to fit into into the same spot. The latter causes bad objects sometimes, because Rhino puts multiple control points into the same spot. This is why I posted the 3dm file in my original post. It’s a clear example of the aforementioned unwanted behaviour.
I completely understand the request for ‘proper’ proporitonal distribution, but that is very diffferent from matching closest points. They accomplish different things - what you show is not a problem with matching by closest points it is a request for a third type of matching - which is fine and valid… In short, don’t use closest points in the situiation you show - it makes no sense there.
You are correct, I think that making this an additional option along with the existing ones would suit everyone’s needs. Any chance for this to be implemented in Rhino 7, or it’s targeted only to Rhino 8? Thanks!
A relatively easy way to get there in one extra step is to Flow the edge points or two points, from the existing edge to the target edge or curve, and then match by closest points
(note SubCrv for some reason seems to flip the direction so you need to set the curve in the opposite than expected direction or choose the ‘wrong’ end of the base edge. I’ll see if that is something we can fix, it shows up in Loft with SubCrv as well)
The idea is to be able to match the surface edge to the target edge or curve on surface in the way the “Match edges be closest points” does (partially, not using the entire length of the target edge or curve) while preserving the original distribution of the control points of the surface to be matched before the “Match surface” operation.
A very simple example would be with a surface consisting 3 control points where the distance between control points #1 and #2 is 5 mm, while the distance between control points #2 and #3 is 20 mm. Imagine that this particular surface edge is being matched to a target edge of another surface with a total length of 100 mm, where the closest points are along 75 mm of the total length if using the “Match edges by closest points” option. So, the 5 mm and 20 mm distances between the 3 control points of the original surface must be spread across the 75 mm of the target edge. Turning on the “Keep distribution” option (or whatever name you decide is best) would result in having 15 mm between control points #1 and #2, and 60 mm between control points #2 and #3.
Hi Bobi - it looks like matching for position to a sub curve (not with closest points) - and snapping the SubCrv ends to the ends of the edge to be changed - gets you there as well - then a match with closest points to achieve the match you actually want.
Hi Pascal, in my Rhino 7 the things get crazy as I try various ways to match with the hidden option SubCrv option that you proposed. The latter actually flips the matched edges, which is quite strange considering that it seems OK while “Refine match” is turned on. However, turning off the “Refine match” option flips both sides for no obvious reason. The “Flip” button in the pop-up window only flips the direction of the matched surface relative to the target surface, however, there is no button to flip the sideways direction. Even if I preliminary apply ! _Flip to the target curve, the matched surface still flips the same way. I think that this is a bug, because the wrong result happens no matter what’s the direction of the target curve and no matter if I click on the left end or the right one. The bug happens any time as long as long as “Refine match” is turned off.
This is why I proposed to add sliders similar to “Blend surface” so that the user could adjust the limits of the matched edge at any time subsequently, as well as to fix the direction if Rhino does it wrong the reverse way.
Hi Bobi - yep, my post is not meant as a substitute for enhancing MatchSrf, only as a relatively painless way to get the results I think you want. As I mentioned above someplace,
That will heavily reduce the time for experimenting with different target curves on surface (as the green and blue curves in this sample file) and will also eliminate the need to preliminary split the target edge, which brings other negatives to the model that affect its *usability.
