Match G2 and Zebra not working on a seemingly simple surface

Can anyone spot why this would give Rhino problems?

The red area is after I’ve done a surface edge match in Rhino, while the green I had to transfer the surfaces to Alias to get to match up properly.

no-g2-after-match.3dm (64.8 KB)

Hello - I don’t know - nothing jumps out at me. I’ll get it on the pile for the developer to have a look.

Hm. it’s interesting, well, to me anyway, monkeying with this- moving one point - the third edge point to the third point of a matched edge curve nearly gets you there as well.

And if you insert a knot, as Alias did, then a Match for tangency makes it good:

So the key is that edge point, it looks like - if that edge can match the target edge G2, we’re good.

https://mcneel.myjetbrains.com/youtrack/issue/RH-54871

-Pascal

1 Like

Ok, here’s another one, and this appears with both BlendSrf and MatchSrf, and I just cannot figure it out:

bild

blend-or-match.stp (31.0 KB)

Where does the kink in the middle come from? I wasn’t able to correct it even with MatchSrf History using the MoveUVN tool!

Again, I had to take the surface into Alias to straighten it out…

Ok, I just read there that blend curves do not suffer from this, so I’m using those and EdgeSrf as a workaround to get history while designing the surfaces:

This also gives you a nice curvature preview that’s live, however although EdgeSrf is fully history enabled, it is unfortunately only G0 so you have to go in and manually match when you’ve locked the surface design.

So, right now, I’m really worried about MatchSrf, and the BlendSrf tool is almost useless to me, due to these serious bugs mentioned above, and also what I reported earlier here:

Has BlendSrf always been so broken? Sadly, that’s the only way to get a skewed G2 match that I know of in Rhino, because for example, neither MatchSrf nor BlendCrv has it due to the weird UI inconsistencies that you find in so many functionally similar, yet seemingly arbitraily limited tool options…

If you look at the input surfaces with CurvatureGraph and/or CurvatureAnalysis, I think you can see where that “comes from,” the small surface has a relatively ‘sudden’ curvature change that ripples through the blend. What exactly did you do to it in Alias to ‘straighten it out’ and what was the actual result? Why was this made as 3 surfaces in the first place?

I know the surfaces don’t line up, and that is what I was trying to correct:

bild
Rhino

bild
Alias

But I guess I ended up falling into a similar “trap” as I did in this thread, because from a bit of testing, it turns out that Rhino never does edge align with BlendSrf or MatchSrf either so I don’t know if there is any way to correct it using History in Rhino (other than the workaround I posted above)?

EDIT: I just realized that this is why MatchCrv also behaves so weird when you try to match to a surface edge… Rhino really never cares about edge direction…

No that’s not what I’m talking about. You’re blending between 2 untrimmed edges, the edges will be aligned and GCon confirms that they are. The smaller surface is not really perfectly fair, it tightens up too much towards the blend edge, and Blend and Match are precisely matching that curvature.

Again, what does Alias actually do different, and why is this even being done as 3 surfaces?

I don’t think the angle you’re approaching my problems from is relevant, unfortunately.

Also, I’ve concluded that it was a mistake to add to my original problem report here. Could a moderator please split out everything from Oct 19th and onwards, as that has to do with “Blend and Match doesn’t edge align” and not surface G2 alignment.