This is a surface that was previously matched to the underlying surface. Then I slid the second and third row control points around a little bit using the MoveUVn tool, and this happens:
Why does the command move the surface by almost a millimeter?
Hello - it should not do this, of course, but the problem is the target surface is rational - this causes extra problems, and I do not know if these are easily solvable, for MatchSrf. If you RebuildUV the target surface in U, it should behave.
The surface that is put into the document has the ‘flip’ flag set (i.e. not the natural normal) but the preview does not know about that flag.
Thanks. So I’m working a lot with revolves and lines on this current model… so it’s a bit weird that Rhino has trouble handling (too simple?) surfaces itself created from its most basic tools…
Ok, so how do I convert them or prevent them from being generated by Rhino’s tools? I’m used to having a checkbox that simply turns them off. Does Rhino have something similar?
The surface is rebuilt on the ‘around’ direction to a degree-3 non-rational surface. Specify how many points in that direction. Deformable revolves can be deformed smoothly with point editing.
Deformable = No
The resulting revolved surface is an exact revolve: a rational surface with fully-multiple knots at the quadrants. This kind of surface is not easy to deform smoothly by point editing.
Circle and Arc commands do not appear to have an option for non-rational results.
Rebuild or RebuildUV will convert a rational cuve or surface to a non-rational cuve or surface. The conversion will not be exact because a circle or arc cannot be exactly represented (no deviation) by a non-rational NURBS curve/surface. However the deviation from exact can be minimized by increasing the number of points - more points results in less deviation. A circle rebuilt as a degree 3 curve with 8 control points has a maximum deviation of 0.11% of the radius. With 16 control points the deviation is 0.006% of th radius.