They are ridiculously subtle (when controlpoints are selected, the highlight colour obscures the u/v colours) and also not always used in other places, menus, icons with any consistency.
For example the icons for selU/selV to select rows of control points in u or v direction should really be coded by red and green.
1 Like
Literally one of the first things I posted about when I began using Rhino in around 2019 (and even so I found a thread about it from 2015).
Like, you had an employee with the ability to fix this and he’s bloody retired by now even!!
1 Like
I do not know why that bug got prioritized the way it did. I will move the issue from that thread to my list as well. That will cover labeling the U and V edges when grips are on for the object.
2 Likes
I also upload a new image in my previous post, using your image as a base to compare with and without U/V indicators. If you make a poll and ask for opinions, I’m pretty sure that the version on the right side will win by a huge margin. 
Here, I added “U” and “V” indicators along their corresponding surface edge:
In order to eliminate the need to add extra arrows, the “U” and “V” indicators could be placed at the 1/4 of the entire length of the surface edge’s origin (from zero to positive direction). For example:
1 Like
Just posting several examples as a reminder to the Rhino developers that the “Blend surface” tool is extremely flawed:
https://discourse.mcneel.com/uploads/short-url/kqGdxelmPZIa2UA4lyvVyR4CmsX.3dm
Misleading preview:
Resulting surface:
The simplest possible degree 1 surface (bottom left):
Overly-complicated output surface:
Future “Blend surface” in Rhino 27 (maybe?):
7 Likes
I think this all boils down to approximation-over-accuracy philosophy. It is extremely difficult to match a surface manually and automatically if the affected edge is strongly curved or non-smooth. I think a output-surface which has evenly or harmonic distributed control-points is in such scenarios often better, than perfect continuity.
Technically, whenever you see Rhino adding extra spans, it basically tells you that Rhino cheats to reach the continuity constraints. The closer the cps move to the edge and the more points you add in total, the less numerical deviation you get. But of course you also get a much worse surface, with bad flow of curvature (=> bad reflections).
In the end, its also the task of the user to improve matching conditions, but I completely agree with Bobi here.