Do you have an example to support this claim? The numbers you show look a lot like floating point noise.
Yes, I uploaded a test file just a few posts earlier. Try to increase the degree of the yellow surface in this picture.
STRUGGLE BUS (test it with Blend surface).3dm (893.1 KB)
Nearly every surface of this type that I modify in Rhino 7 with “Change degree” gets a slightly different control point weight than the original value of 1. Mostly happens with nearly flat surfaces with degree 1 in one direction and a higher degree in the opposite direction.
Here is another example that clearly exposes a bug in “Blend surface” caused by using a straight surface edge as an input. You will notice that “Blend surface” will fail to generate a clean surface when using the straight edge of the square surface as in input, despite that both input surface edges have an equal number of control points. The yellow surface was rebuilt with “Rebuild UV” and is supposed to have a clean, equal structure. The “Interior shapes” option is disabled…
However, if you move some of the end control points of the latter just tiny bit, in order to make it curved (no longer straight), then suddenly “Blend surface” will work as expected and the “Interior shapes” option is active.
Test these with Blend surface to expose the bug.3dm (1.5 MB)
The end of the video also reveals another bug in “Blend surface”, this time related to the History recording. You will notice that the G2 curvature continuity got improperly updated as soon as I moved the corner control point back to its original position. The expectation is that the History should be able to update the blend surface while retaining the G2 continuity.
I changed the degrees of the yellow surface from 4x1 to 5x5. The changes in the weights were in the 15th to 17th decimal place. That is due to floating point round-off error in the calculations.
Why is the original surface “rational” with weights equal to 1 rather than “non-rational”?
I’m not a programmer and I don’t know how these calculations work behind the scenes in Rhino, but in my opinion, the weight value of 1 of all control points should be kept unchanged after changing the degree. As noted before, even the slightest change of CP weight disables the “Interior shapes” option and leads to an unwanted dense output blend surface.
If you watch my last video above, you will notice that moving one of the end control points up (making the input edge curved) actually fixes the bug. Then, once I moved the same control point back to its original position (the input edge became straight again), the blend surface was still clean, even though it was overly-dense just a moment earlier using the same straight edge as an input.
For some reason “Loft” does not suffer from the same bug.
The problem is not the fact that the surface is flat, but I do see that it acts very weirdly.
When you make that surface planar (currently it is not detected by SelPlanarSrf) and move any point, even in the surface’s plane, the BlendSrf is adjusted correctly.
The weight issue is odd as well. I made this sample from your file that isolates the issue very well:
All points are 1 except for the selected point (weight is 0.9999999999)
after changing it to 1.0:
I had this issue with flat input edges thousands of time over the years. It mostly happens on degree 1 surfaces, but sometimes on a higher degree surfaces, too. Even a totally flat and simple rectangle has caused some issues. Earlier in this topic I posted a few more examples where “Blend surface” behaved weirdly:
Here is another case, this time captured on a video:
@Gijs , I added some extra text in my post #102, just below the video called “Blend surface has a serious issue with flat surface edges”.
the bug you show in this video is actually not a bug with how History updates the surface, because it correctly reapplies the settings. If you Run BlendSrf afterward and hit the Edit option, you’ll notice that Interior curves is still off.
The actual bug is that BlendSrf doesn’t adapt to the highest degree surface
RH-91943 BlendSrf makes too complex blends
Thanks for adding this to the pile! I hope to see it fixed in Rhino 9! 
Due to this particular bug I often avoid the “Blend surface” tool and use “Loft” instead, followed by “Match surface” to achieve G2 curvature continuity.
P.S. Please, also check the bugs described in posts #25 (Misleading preview of the “Interior curves” versus the actual output surface) and #85 (needs a “Flip” button) in this topic.
From my experience, those handles match the control points IF the user don’t adjust the inner handles. The outer handles show a preview of how the control points will be distributed. However, even the slightest modification of an inner blend surface handle will destroy the overall flow of all control points of the resulting blend surface, making it literally unusable.
The goal is to avoid the chaos placement of the control points, because this particular bug makes the inclusion of adjustable inner handles worthless.
I’ve always said it: tools like Blend srf and Match srf (along with the revamped Rhino 9 patch) should be the state of the art in a nurbs surface modeler like Rhino. There is no excuse, especially after decades of continuous development. They represent the basis of modeling; tools that allow you to seamlessly connect portions of surfaces that would otherwise be disconnected. These tools work not yet. Optimal way, and still have few options, which means limited possibilities.
They should be rewritten or paid more attention, on the model of the defunct VSR plug-in, at least
Very well said. While I welcome every improvement in any tool in Rhino, I’m surprised that “Blend surface” and “Match surface” receive the least love from the developers… This is super strange, because both “Blend surface” and “Match surface” are basically the main tools of every NURBS modeling software. If you read the first several proposals in this thread, they are all targeted to these two tools in Rhino.
Importance-wise, both aforementioned tools are closely followed by “Rebuild” (or even better, the “Explicit control” option built directly inside the modeling tools in Alias) and “Patch”.
“Sweep 2 rails”, “Sweep 1 rail”, “Loft” and “Network surface” are mainly used to build a primary surface that needs some additional rebuilding to work properly.
Unfortunately, there is still no “Sweep 3 rails”, and “Network surface” is not a replacement due to the loose deviation and very high density of control points to achieve a surface close enough to the input curves and surface edges.
Yes please!
Or better the capability to invert the handles position without bugging the construction.
Today if you get a flipped blend handle and you try to move at the opposite position the command stop to work.
Yet another bug that must be fixed is the inability of “TweenSurfaces” to build a proper median surface between two surfaces that are positioned at 90 degrees or greater relative to each other. Here is a detailed explanation (and a partial fix for planar surfaces only) of the bug:
Yet another urgent improvement of Rhino must be the addition of “Shading falloff” for the tiny objects in the viewport. This is a 3d performance fix that could easily increase the framerate on projects that consists a huge amount of small details such like screws, trees, buildings etc. I believe that it’s fairly easy to implement, and must be used by Rhino 9 WIP before it’s too late. Here is a deeper explanation of the proposal:
Check the post to which I reply here. Could someone with the today’s Rhino 9 WIP test several cases with building a blend surface between two existing surfaces with different degree and number of control points?
The latest Rhino 9 WIP is supposed to include a fix for this bug:
Thanks! That’s a great news. Often times I’m forced to change the degree of certain surfaces (even simple planes) just to avoid the unnecessary creation of multiple spans.
If you adjust just one of the “Interior shapes”, is the resulting blend surface smooth, or its control points are chaotic? That’s also one of the weird bugs mentioned in my linked post.
