I’m curious what’s the problem in this particular case with “Match surface” while using the “OnSurface” option. Despite having a target curve pulled on the target surface (blue), the surface to be matched (white) fails to match the former accurately and goes in a wrong position instead.
Match surface to curve on surface fails.3dm (301.7 KB)
Hi Bobi - I have not dug in very much but I suspect the underlying problem is that both surfaces are rational. That has never worked as well.
-Pascal
Hi Pascal! You guessed it right - the issue is caused by the blue target surface. Once I rebuilt it into a single-span Degree 5 with 6 control points in either direction, the “Match surface” command worked properly.
In my opinion, cases like this one should be treated by Rhino under-the-hood, by temporarily using a rebuilt surface as a substitute to the rational target surface.
Searched results are full of math, so allow me just be lazy and ask,
what are rational surfaces? Do we call degree 1 to 3 surfaces rational ones? So matching from high degree to 1 to 3 degree surfaces is problematic?
Rational curves and surfaces are ones where one or more of the control points have weights other than 1. These are necessary for making objects like accurate circles and ellipses and their derived surfaces using NURBS.
Wow, thank you very much! This explanation is much easier to understand than the videos I searched!
It would be really helpful if we could easily differentiate rational stuff from non-rational. Maybe control points could visually look different, for example.
Better yet, we need a “rebuild surface”/“surface info”- panel with explicit control about surface degree, control points and spans.
Explicit control as an integrated option of the majority of surfacing tools (similar to what Alias offers) have been requested multiple times over the years (since Rhino5), but looks like it will not happen soon in Rhino…
The reason it doesn’t work with this surface is because folks at McNeel are too lazy to fix bugs like this one.
You can can do the match the old school way. Just trim the cyan surface with the blue curve (using ExtendCrvOnSrf) and then match to the resulting surface edge (match by closest points). Then copy the result to the clipboard and undo twice and paste in the matched surface. You can write a macro to make all that one operation.
There is no reason Rhino can’t match a surface to a rational surface. Anyone at McNeel that tells you that is throwing up a smokescreen to avoid addressing their bugs.
The real problem in this scenario is the other surface (the white one in the picture). If you use your workaround for matching or the one I described above, you need to first raise the degree on that white surface to at least degree 3. As a degree 2 surface if you match for tangency it will destroy the internal tangent continuity in the middle of the white fillet and it will turn it into two surfaces (a polysurface) where the two surfaces will not be tangent.
Also, I’m curious how that edge of the white fillet ended up not tangent to and not on its base surface. That should not happen. You may have stumbled on another Rhino bug.
@Rhino_Bulgaria thanks for reporting, I added RH-78110 Match surface to a Rational surface
Can you indicate how you constructed the two fillet surfaces, as Jim was asking?
Hi @Gijs , I created the red 1 mm fillet surface between these two target surfaces:
Smarter Split 2.3dm (191.7 KB)
Once I did that, I extended the fillet with ! _ExtendSrf and “Type=Smooth” and “Merge=No” options, in order to have a separate surface (the white one). Then I used ! _Pull on the upper edge of the white surface to make the blue curve interpolated on the blue surface.
Since Rhino lacks a “Extend surface on surface” tool (maybe it’s time to make one?), my idea was to do it manually the old fashioned way.
By the way, I think that ! _FilletSrf should offer an option to create an extended fillet surface which goes all the way along the entire lengths of the trimmed surfaces, even though a portion of them is deleted/invisible. That could eliminate the situations where the fillet is only partial due to the target surfaces being trimmed.
The same issue also happens here at the 0:27 minute and 1:39 minute of this video. Note that the end fillet surfaces were not extended due to the inclined surface that could not provide a geometry data for Rhino to further extend the filet beyond its end:
! _CreateSolid also failed to create a solid from the surfaces in the video, despite that I extended the top fillets.
I know how to do it manually as a workaround, but the main issue is that certain tools in Rhino are not optimized for such cases, hence they leave a lot of room for improvements. Being unable to match a surface on a rational target surface (exact radius surface) is a huge limitation, especially for those people who often deal with filleted geometry.
As I mentioned in an earlier post, a possible solution is for Rhino to use an alternative rebuilt version of the target surface just for the calculations, so that the user will not be forced to do it manually every time:
A visual cue would be so great! fwiw - I run MakeUniform on anything that starts to act funny, the way that rational curves/surfaces do, and that will bump them back to uniform. This will change the shape, but will cause fewer problems down the road.
Here’s a selection tool, it may help, for now.
SelRationalSrf.py (860 Bytes)
To use the Python script use RunPythonScript, or a macro:
_-RunPythonScript "Full path to py file inside double-quotes"
-Pascal
One method to extend a fillet on a surface is to start with a curve like your blue curve. Make sure it is matched for tangency with the edge of the fillet you are extending then rebuild the curve with lots of points. Then use the Fin command to create a 1mm fin (radius of the fillet that you are extending). Then rebuild the fin to a high number of points. Then use Sweep1 to create the extended fillet using the edge of the fin as rail and the align with surface Frame style.
This is not very fast but is a extremely accurate way to extend a fillet to wherever you want it to go. The reason for rebuilding the blue curve is that the Fin command doesn’t like the multiple knots created by the Pull command and Sweep1 doesn’t like the multiple knots created by the Fin command. Without those rebuild steps the result is much less accurate. Here’s the file:
extend_fillet_on_srf.3dm (70.7 KB)
Thank you.
Your workaround method of changing the degree of the target surface to 3X3 demonstrates the problem is not really about matching to a rational surface since after changing degree the target is still a rational surface. Also if you don’t want the surface being changed to get messed up that surface has to have its degree changed to 3X3.
I have used this approach a few times, but in general I prefer to rely on making copies of the main surfaces and untrim (if trimmed) or extend (if they are too short) them, then make true fillets in-between. The advantage of the latter is that it gives an accurate representation of the fillet in its natural location by limiting it by the input geometry (which sometimes is also a negative), whereas the approach you described gives more freedom to create fillets in custom directions (but sometimes this is also something to avoid). This is mostly needed in areas where car door sills contact with their corresponding rubber seals.
Why not just FilletSrf with Extend, or Untrim the cyan surface temporarily to make the fillet? (the latter giving the most accuracy)
The idea is to be able to create an extension of existing fillet surface following one of the primary surfaces, where the ! _FilletSrf tool can’t build a proper surface. This mostly happens on the corners of door sills, inner mounting points of exterior panels and other areas for body-in-white modeling (a.k.a. Class-B surface quality using mostly fillets).
Would be awesome to incorporate something into display modes, sorta like Backface settings!
