Bugs in Rhino 6 + suggestions for the BlendSrf command

Yes, unfortunately, this is the exact same slow workaround that I also use, since Rhino’s “Blend surface” and “Match surface” both lack an option to control the control point count and distribution directly.

@pascal and the “McNeel” team as a whole, just wondering if you have any intentions to improve the “Blend surface” according to the suggestions in this topic? :slight_smile: That will easily make the tool 200 times more powerful and save lots of time and frustration to your customers. Thanks!

4 Likes

I have reported this HUGE bug a few times already, but it happens on a daily basis and is hugely unbearable, because the resulting blend surface has nothing in common with the misleading preview that shows far better quality than the outcome.

Try to build a “Blend surface” between the two surfaces in the attached file, then slightly adjust some of the handles. You will notice that the control points are placed in a chaotic fashion, unlike the much more natural control point distribution in the preview.

Blend surface fails a lot.3dm (166.1 KB)

Default settings:

I slightly modified the bottom two handles. Notice that the transverse icocurve at the middle of the blend surface got distorted, and despite moving the handles to their approximate original position, that isocurve remains distorted and no longer can be made straight again:

The resulting blend surface is extremely distorted, leaving the user disappointed by the misleading preview:

2 Likes

Things like that should be fixed as a top priority IMHO.

1 Like

I agree, it’s pity that this bug happens all the time, considering that it results into bad quality while trying to do G2 surfacing expected to be good due to robust modeling tools. You will notice that the misleading preview from my 2nd screen-shot above already shows extreme deviation of the transverse isocurve, despite that the control points look all good before hitting the “OK” button. This means that Rhino already applies bad quality to the blend surface even before it’s built.

1 Like

Bobi, you should be hired by McNell. Your suggestions and insights are very important. Still in Rhino they are stuck in the stone age for certain tools. I’ve been trying to tweak the blend surface tool for years, and still, it doesn’t work so well.

1 Like

I often find myself using the combination of “Loft” + “Match surface” + “MoveUVN” instead of “Blend surface”, because the latter does not deliver the great quality that the preview promises. It’s a far slower solution, but also much more accurate and smooth while also having fewer control points. Just like this example in post #11 reveals:

2 Likes

Bobi, what a lot of people don’t understand is that you work with Rhino on it, you use it seriously. McNeel programmers develop often sloppy tools and don’t even use what they make. We should make you a statue!

1 Like

It’s true that the majority programmers are probably good in doing coding, however, they are not the ones who are working as full-time 3d modelers, hence they probably only test their tools in simple 3d geometry (just a speculation) or geometry shared by existing Rhino owners who report bugs. I can fully understand that, because they are programmers after all. However, that also means they have just a minor glimpse of what’s actually necessary, in order to improve their own tools to be capable of doing real projects that are far more complex than a basic box or a cylinder. By coincidence, yesterday I mentioned something about that in another topic:

1 Like

I think it’s also an underrated factor here named: the marketing department (in general). Fixing tools is fully understood only by a few. Developers are doing what the marketing department thinks will be selling their software more. IMO marketers and sellers don’t understand mostly that newcomers after a few months of working with Rhino won’t understand why some tools produce bad geometry and they will think that is their fault. It’s much easier to sell a catchy new feature even if it’s not finished than polish what already is. But it’s a short vision thinking. I had the same as the Modo user so it`s not a problem of one firm. In the longer-term fixing and polishing old tools is a hard decision but only one right.

Big fishes should see that users are frustrated when have to look for 1000 scripts to omit problems which some tools are producing. They should also notice that newcomers will have a much easier start if all tools will work more predictably. For newcomers messy CV is not a problem but when after using a few tools they will notice pinches, holes, naked edges and match surfaces which won’t work because CV density is too heavy or works in some unpredictable way.they will say I don`t know how to use that tool.

So fixing existing tools and make them similar works not only for more experienced user but also for fresh ones too but they don`t know how to ask about that.

2 Likes

I completely agree with you. Improved main surfacing tools also boost sales and helps the image of the program. Imagine what frustrated users will say about Rhino due to issues with underdeveloped tools, and what if they are satisfied by its good capabilities. Not to mention that existing Rhino users want to see real improvements of the surfacing tools to justify upgrading to the newer version.

2 Likes

I think a developer should have a user (modeller) next to him. Inconsistent tool development is a big bad thing for software.

1 Like

This is listed here: RH-73865 BlendSrf outcome doesn’t match preview

1 Like

In a perfect World, that would be the same person who do both, programming and modeling/testing of the tool. :slight_smile: We can only hope that the “McNeel” people who write in this forum have a direct contact with the leading staff at the company and could advocate for the need of better surfacing tools. Unfortunately, Rhino slowly loses ground and tries to be a SubD modeler instead of offering improved NURBS capabilities.

The only sensible improvement in Rhino 7 compared to Rhino 6 was the addition of “Edge continuity” analysis. “Refit trim” produces too much deviation that makes the tool almost unusable. “Ribbon offset” is only usable in very rare occasions for mould making of very distorted/organic shapes. The majority of companies produce moulds for mechanical designs, to this tool is rarely needed. The “Straighten” option of “Blend surface” is also rarely needed, because manually added shapes where the user specifically needs them is a better solution. I can’t find any other NURBS surfacing tool that have been improved so much across Rhino 6, Rhino 7 and Rhino 8 WIP. They largely remain the same.

Rhino 7 focuses a lot on SubD and I can see the reason for “McNeel” to want to grab as much “3d mesh modeling customers” as possible. However, speaking from a NURBS surfacing point of view, “Quad remesh” and SubD are not even related to NURBS. Also, conversion from SubD to NURBS is flawed around the star-like edge connections.

1 Like

I noticed that this particular huge bug will most likely remain ignored by the developers and won’t be fixed in Rhino 7… :slight_smile:

Release target: 8.x

it could be worse!

Screenshot 2023-04-14 130958

This is a classic case where “Blend surface” fails to deliver a clean output geometry despite the fact that the input geometry is very simple.
Note that the blend surface on the left side is overly-dense, even though the bottom surface is the simplest possible, i.e. a basic plane with the least amount of control points. In this case, Rhino should be smart enough to interpret the flat plane in the same way as it reads the more complex surface on the upper left corner.

Blend surface must be fixed.3dm (276.3 KB)

The same issue with gazillion control points happens with “Match surface” while trying to match the plane to the upper left surface. :slight_smile: If I’m not mistaken, the VSR plug-in for Rhino 5 had some option called “Adopt parametrization” that tried to match the surface structure of the matched surface to improve the quality and reduce the amount of control points to the bare minimum.

1 Like

The above post shows a good possibility to take advantage of the “Refine blend” option shown in the picture below, choosing between 3 possibilities: “Bezier surface” (automatic degree 5 with 6 control points), “Rebuild surface” (manual control) or “Minimum CP distance” (manual control):

Note that some options could be expanded or shrinked if necessary, in a similar fashion like the Rhino Options panel. That keeps the pop-up window as small as possible when the additional options are not used.


The “Use a guide rail” option lets you pick an existing curve or surface edge to influence the shape of the blend surface, sort of what the rail in “Sweep 2 rails” tool does. You can also pick multiple rails for the proposed “Blend surface” tool, including ones inside the blend surface (again, just like “Sweep 2 rail” lets you do).


The “Match target edge” option lets you pick the side edge of the target surface or an existing curve to match the tangent direction of the blend surface in that spot.


The “Bulge” option works in a similar fashion like the “Bulge” option of Rhino 8’s “Fillet surface” tool, allowing to modify the bulge influence of the blend surface (only when G2, G3 or G4 is used in at least one end of the surface).


The “Minimum CP distance” will prevent creation of a blend surface with gazzilion control points, because it lets you limit the distance between the closest control points. For example, settings a 3 mm “Minimum CP distance” for a blend surface whose shorter edge is 20 mm long will result into a surface with no more than 7 control points along the edge. In case that the shorter edge of the blend surface is 20 mm long and the user sets a “Minimum CP distance” of 25 mm, the blend surface will have just two control points, which is the bare minimum for a 4-sided surface to be created.


The “Match target isocurve U direction” and “Match target isocurve V direction” options let you swap the direction (either U or V) to avoid the typical bug in the current weak implementation of the "Match target isocurve direction"option found in “Match surface” that often gets confused and mixes both directions into one, leading to highly distorted unwanted results (sometimes even crashes Rhino).


Additionally, a new Command line option could be implemented, such like “Menu=Expanded” (expands all menus in the pop-up window) or “Menu=Compact” (closes the extra options to make the pop-up window similar to the current implementation). This command line option should be remembered for the current session.

4 Likes

All of the above suggestions must be implemented in Rhino 9.