Bugs in Rhino 6 + suggestions for the BlendSrf command

[Rhino_Bulgaria (Bobi)]

Hi there,

Currently I’m using Rhino 6 Evaluation and I managed to find several bug in the program that were not present in Rhino 5.

1. I have 3d Connexion SpacePilot (the old discontinued model, not the more recent “SpacePilot Pro” one) that works flawlessly in Rhino 5, but in Rhino 6 I noticed that 3d Connexion’s automatic rotation center no longer can “see” through solids and surfaces that were given a custom “wireframe” viewport setting through the “SetObjectDisplayMode” command. This bug is highly inconvenient, because the rotation center struggles to find the proper location on top of the visible geometry, and uses the invisible geometry of the nearby “wireframed” objects as a reference instead. I mainly use the “SetObjectDisplayMode” command to hide the geometry of objects while still having their wireframe visible in the scene. For me, this is a game changer in Rhino 5 and being unable to use it properly in Rhino 6 prevents me from buying the program at this moment.

2. Rhino 6 has issues with custom arrangement of toolbar menus. For example, every time I start Rhino 6 with various toolbars arranged at the bottom, the “Osnap” is missing, even though it was there in the last session. No matter how many times I save the toolbar settings, the “Osnap” toolbar is always missing and probably this error is caused by the presence of other toolbars at the bottom. Usually I place the Osnap toolbar at the bottom and then place several tabs with other toolbars on top of it. That was not an issue in Rhino 5 where everything worked as expected every time, so I consider it a bug in Rhino 6 where it is unable to do so.
   Since it works in Rhino 5, I think that this bug in Rhino 6 is something that could be easily fixed by the team at McNeel.

3. In my Rhino 6 Evaluation version (6.2.18065.11031, from 6.3.2018) the “BlendSrf” command sometimes performs worse than the same command in Rhino 5. Maybe this is caused by the introduction of the newly adopted “Interior shapes”. Example:

a) When I build two simple flat surfaces with Degree 1, then use the BlendSrf command between them, Rhino 6 will create a Blend surface with Degree 5 (CV count = 6) and Degree 1 (CV count = 2). Just like it did in Rhino 5.

b) But… If I rebuild one of these perfectly flat surfaces with Point count 10, Degree 3 and span counts 7 in both UV directions, the Blend surface that I already had (with History enabled) will rebuild itself into a surface with Degree 5 (CV count = 6) and Degree 3 (CV count = 4).

c) If I do the same with the second surface, then the Blend surface rebuilds itself into a surface with Degree 5 (CV count = 6) and Degree 3 (CV count = 10). This also happens if I delete the Blend surface and try to build a new one. Then it will automatically have 10 rows of control sections (shapes), which is very disturbing, because that will not allow me to have a more smooth control over the shape of the blend surface. In Rhino 5, I can add as much extra shapes (through the “Add shapes” button), but the default control shapes are always two (at the start and the end of the blend surface), allowing me to manually adjust the intermediate shape the way I wand. Since Rhino 6’s BlendSrf command will add a lot more control shapes by default, I no longer can have an easy and smooth control over the whole shape, forcing me to edit multiple shapes at variable rate.

If I only rebuild one of the original two surfaces used for the creation of the blend surface inbetween, the history is still enabled and any change in the control points of these two surfaces will affect the blend surface, too. However, if I rebuild the 2nd surface, the blend surface will no longer have its history enabled.

I also noticed another bug. If I use the BlendSrf command with the “Interior shapes” option off, sometimes the resulting blend surface will lack proper G2 continuity. This never happened in Rhino 5 where the continuity was perfect at all times. While using the “Interior shapes” option solves the problem, that comes at the cost of many extra control points that were not necessary in Rhino 5 to achieve virtually the same result.

4. There are bugs with History enabled for splines/curves, too. For example, if I match one end of a spline to a surface or solid edge, then I split that edge in another location (or if I extract a surface from the solid model), the spline’s orientation gets flipped automatically. If the history gets broken or “confused” in similar situations, is not it possible to just show a warning, or at least preserve the curve the way it was before the edge/surface/solid was affected with the Trim, Explode or ExtractSrf command?

===================================================

I also have a few suggestions for the BlendSrf command:

1. Is it possible to add a “Relax shape” option whose purpose is to smooth out the middle rows of the blend surface, without affecting the height of the surface at both both ends? The “Same high” option works in a different way, trying to equate the height of the surface.

2. An option “Use guide rail” would help a lot, if we were able to pick a spline that the BlendSfr command could use as a guide for its middle body. This is somewhat implemented in the Patch command and I find it quite useful. Sometimes I use splines together with the “Flow along curve” to affect the position of certain control points of surfaces, including blend surfaces, but that’s also slow and different than having the option by default in the menu window of the BlendSfr command. This will basically turn it onto a “Sweep 3 rail” command.

3. Make it possible to move sideways (along the rail edges of the blend surface) as much control points as the user wants, with “Relax” option separately along the U and V directions that affects only the selected control points. The UVN command is too limited and slow in these situations.

4. Ability to divide the blend surface (while still into its creation phase) into a number of sections, where the user is able to set a different, individual continuity setting to each section. For example, if I want to create a blend surface whose last 25% smoothly turn into a crease line, then the program should allow me to divide the blend surface into 4 sections where I set G2 for the first 2 sections (equal to 50% of the total length), G0 for the 4th section (equal to 25% of the total length) and the 3rd section (another 25%) is leaved for the smooth transition between G2 and G0. The resulting surface should have 50% G2 continuity, 25% transition from G2 into G0, and 25% G0.
   In the same way, if we have the blend surface divided into 10 sections, we will be able to create advanced blend surfaces with greater control over the overall shape.
   Some CAD programs feature similar custom input, but in a different way.They allow the user to set a custom length from the end of the blend surface where it will lose its G2 continuity in favour of G0.

[Rhino_Bulgaria (Bobi)]

Another proposition for a vast improvement of the Blend surface is to have an option to influence the control handles by the adjacent edge direction with one of the following settings:

a) Match target edge direction;

b) Match target surface isocurve direction.

That will completely resolve the issue with randomly shaped blend surfaces that require extensive work to be fixed afterwards.

This is where even Match surface’s “Match target isocurve direction” was unable to properly “read” the actual isocurve direction of the adjacent surface:

[pascal (Pascal Golay)]

Hi Bobi - it looks to me like MatchSrf is doing too good a job, if anything , in matching the iscurve directions here - since the trimmed edge cuts arbitrarily across the U&V directions, each can end up being potential target depending where along the edge you ask. In this context you’d need extra UI to specify U or V direction. Your note on the image only points out the direction you care about and not the other one…

-Pascal

[Rhino_Bulgaria (Bobi)]

Hi Pascal, I see what you mean here. Looks like in these situations with diagonally split surfaces Rhino is getting confused which direction is the target one (U or V) and can’t predict the intent of the modeler. And makes an approximation between both U and V directions? This is where a more specific guide (separate options “Match target isocurve U direction” and “Match target isocurve V direction” in the Match surface panel) will help it create the desired matching to the true U or V isocurve direction of the split surface.

Cheers,

Bobi

[Rhino_Bulgaria (Bobi)]

Here we go. Another suggestion for a future improvement of the Blend surface tool and its window.

Legend:

• “Automatic”. This is selected by default and works exactly as the current blend surface matching. *Only showed in my second image.

• “Match target isocurve U direction” and “Match target isocurve V direction”. Matches the blend surface either to the U or V direction of the target surface, as I explained this in my previous post. If one of these is selected, the check mark of the “Automatic” is removed.

• “Match target edge”. Matches an individually selected blend surface handle tangent to the edge of the target surface. Obviously, that will not work if the blend surface’s handle was moved to somewhere in the middle of a target surface. However, to go around this limitation, there is still a possibility to pick either an extracted isocurve or a projected curve on the target surface.

• “Reset handles”. This is self-explanatory. It resets the original position, angle and size of the handles. As far as I know, Rhino’s existing Blend surface tool does not offer this functionality. *Only showed in my second image.

• “Use a guide rail”. I already explained this in detail in my original post half year ago, so I will simply copy that text below. Optionally, this may add an additional row of control points across the middle of the blend surface so that its both ends remain unaffected by the curve rail.
  (quote) “An option “Use guide rail” would help a lot, if we were able to pick a spline that the BlendSfr command could use as a guide for its middle body. This is somewhat implemented in the Patch command and I find it quite useful. Sometimes I use splines together with the “Flow along curve” to affect the position of certain control points of surfaces, including blend surfaces, but that’s also slow and different than having the option by default in the menu window of the BlendSfr command. This will basically turn it onto a “Sweep 3 rail” command.”

• Curvature influence. This is how much the blend surface will follow the curvature of the target surface. Not active (rendered as unpickable grey text) if “Position” or “Tangency” is selected. If the curvature influence is set to the default 100%, this is a true curvature (just like G2, G3 and G4) work normally. If the curvature influence is set to 0%, this will basically work as Tangent, even though the modeler had the G2, G3 or G4 selected. If the curvature influence is set to 50%, this will move the 3rd row of control points (the G2 ones) somewhere between their potential position of G1 and G2. With other words, this will be something like G1,5 and will give a much greater control on how strong the curvature is compared to a true G2 continuity. In many cases G2 continuity is way too much, and G1 is too few. Variable alignment is a huge advantage to people who aim to achieve nearly Class-A surface quality.

• “Rotate start of 1 by”, “Rotate end of 1 by”, “Rotate start of 2 by” and “Rotate end of 2 by” (or just “Draft angle”). This allows the modeler to set individually controlled amount of rotation to each of the 4 handles that are used to control the shape of the blend surface. If there are additionally added shapes with the “Add Shapes” button, they will follow the same rules. Example: If the start of side 1 is set to 5 degrees, and the end of side 1 is set to 0 degrees, this means that the middle of the blend surface’s edge will be rotated by 2,5 degrees in relation to the target surface edge. The pair of blend edges 1 or 2 could be locked (as shown in my image) to simultaneously control the draft angle for the entire edge. Being able to control the draft angle is especially useful when working with products that will be manufactured by injection moulding or by using fibreglass moulds.
  Also, many people want to build a Blend surface that’s at 90-degree angle towards the target surface, so this is a quick way to do that and avoid using the “Fin” tool to extract a curve and build extruded surface normal to the target one.

The second image is an improved menu design that is a bit higher to include a dedicated “Draft angle control” box. The whole menu could be 1/4 shorter if the “Draft angle control” is made as a button that expands the main menu or opens a new window for draft angle control only.
This image has “Rotate start of 1 by” (etc) renamed to “Handle 1a” (etc) if we assume that in the future the viewport display of handles 1 and 2 is changed to 1a, 1b, 2a and 2b. That will better distinguish each of the 4 handles of the blend surface. The padlocks are moved to the left side of the boxes for a more logical appearance. You will notice that I also included “Automatic” and “Reset handles” in the middle of the menu. I added a description for these above.

PS: For some reason the 2nd image appears horizontally stretched in my internet browser.

[pascal (Pascal Golay)]

@Rhino_Bulgaria

“Reset handles”. This is self-explanatory. It resets the original position, angle and size of the handles. As far as I know, Rhino’s existing Blend surface tool does not offer this functionality. *Only showed in my second image.

Hello -
This bit is possible now by clicking on the G1/G2 etc radio buttons - whichever side you want to reset. You can change the continuity setting or just click on the current ones. If you’ve adjusted the handles on that side, they will reset.

-Pascal

[Rhino_Bulgaria (Bobi)]

Hi Pascal, the resetting of the blend surface handles that I described above is about reverting them in their original state (position, rotation, scale) at the very first moment of its existence. Here is an image to explain that visually. Example number 1 on the left shows how the blend surface appears at the very beginning. Example number 2 shows how it looks when the handles were further modified. By clicking on the “Reset handles” box the blend surface handles will go back exactly like they appear in example number 1.

The method you described is also handy and I use it a lot to reset the scale of the handles, while their (modified) position and rotation remains intact. This is a very good feature and if you ever decide to implement the full resetting of the handles in a future update, the existing partial resetting could co-exist as both of them do different job and are equally useful.

Also, I have another proposition for the “Blend surface” and “Match surface” commands. Is it possible to remember the lastly used bunch of surface edges and/or curves that were previously used to build a blend surface or to match an existing surface edge? Maybe an additional clickable option in the command line named “Use last”? This will save a lot of time when a blend surface is constructed along multiple surfaces (or a match surface is run to match a surface to multiple edges/curves) and for some reason the modeler must redo the command.

Another helpful thing for the “Match surface” command is to have a secondary, smart auto-chain option that will limit the latter to only those edges that sit adjacent to the surface that’s being matched. Currently, if the “Chain edges” is activated and “AutoChain” is set to “on”, that will try to select many more edges than necessary. In this situation the modeler is forced to either manually deselect the unnecessary edges, or to manually pick the desired edges one by one while the “AutoChain” is turned off. The “Match edges by closest point” option sometimes helps to force the surface edge to match to the nearby target surface(s) and/or curve(s), even though it may also move away the latest control point of the surface by a tiny amount and that could bring some errors such like the bad object warning when the resulting surface is being joined to the target one.
Here is a visualization of my idea. Example 1 shows the original surface before we run the “Match surface” command. Example 2 shows how the surface is matched to the adjacent surfaces when “ChainEdge” is activated and “AutoChain” is turned on and “Match edges by closest point” is not on (as I said, sometimes it’s a reason for potential errors). Example 3 shows how my proposed limited auto chain could work, by offering to match the surface only to those edges (and/or curves) that are close to the surface we match. Note that this will select the full edges (and/or curves) even if the surface we match is close to their middle area. This is a big time saver when the amount of edges and/or curves is above 10-20. Sometimes I match a surface to more than 50 edges together and my intent is to match to, say, only 17 of these, while the remaining 33 edges I have to deselect manually. Depending on the shape of the model, this may lead to frustration, especially without a 3d mouse for camera navigation.

[Rhino_Bulgaria (Bobi)]

An updated version of the “Blend surface” panel with some extra controls and rearrangement.
Rhino 7, is that you?

[Rhino_Bulgaria (Bobi)]

This is what Rhino 7’s “Blend surface” should be capable of:

Blend surface - Rhino 7.3dm (385.9 KB)

[pascal (Pascal Golay)]

Hello - Thanks - you’re losing me a bit on the ‘match target isocurve’ bit. Probably needs its own UI. I think, though, that matching side edges is an understandable and legitimate thing to be able to do, whatever the UI.

Related items on YT:

https://mcneel.myjetbrains.com/youtrack/issue/RH-35431

https://mcneel.myjetbrains.com/youtrack/issue/RH-2269

-Pascal

[Rhino_Bulgaria (Bobi)]

Hi Pascal, thank you for taking note on that matter! I see that many people already requested edge align of the “Blend surface” handles years ago.

By the way, I misspelled some words in the 1st image from my last post. I just updated the image. Hopefully it’s easier to understand now. I will post it here just in case:

To clarify. My proposition for the “Divide edge” option is basically a “Rebuild surface U” inside “Blend surface” while the latter command is still active. Being able to divide the “Blend surface” into custom number of segments greatly increases the ability to manually adjust its shape via control point manipulation, prior applying “Match surface”. Also, the user would be able to try different number of segments (5, 10, 50 etc) until he or she is satisfied by the result at the given tolerance. This could be even more useful if Rhino 7 implements a live preview of the gap between the target edge and the blend surface edge while running the “Blend surface” command.
Along with “Divide edge”, I also proposed two more options for rebuilding the surface: “Distance from edge” (similar to “Refine match > Distance” in the “Match surface” tool) and “Minimum CP distance” (it will prevent building of blend surface with extremely dense control point structure).

Several days ago in another topic you posted an image showing one improvement for “Blend surface” in Rhino 7 WIP that build a simplified surface. Rhino 6’s “Blend surface” creates an excessive number of control points that are not necessary most of the time.
The following case is just one example of that. Check the picture with the Zebra stripes. Note that the two input surface at the left side were cut by isocurve, exposing a very clean edge to work with. However, “Blend surface” was unable to obtain the same number of control points as the input surfaces, ultimately adding extra control point rows. On the right side, however, I drew two curves on the input surfaces with the “Interpolate curve on surface” command, then I used them as target curves for the “Match surface” with the “CurveNearSurface = On” option. Despite being non-parallel to the isocurves of the target surfaces, the edges of the matched surface remained as simple as possible while achieving G2 continuity. I think that “Blend surface” also should be allowed to match to inside of target surfaces in a similar fashion (currently, it’s limited to use only surface edges as input).
Loft plus Match surface.3dm (7.4 MB)

[pascal (Pascal Golay)]

@Rhino_Bulgaria

Several days ago in another topic you posted an image showing one improvement for “Blend surface” in Rhino 7 WIP that build a simplified surface. Rhino 6’s “Blend surface” creates an excessive number of control points that are not necessary most of the time.

Hello - this is the same in V6 - if the edges are simple (untrimmed) , then the blend surface can be as well.

FWIW, I generally loft and match in preference to BlendSrf-ing

-Pascal

[Rhino_Bulgaria (Bobi)]

It’s a bit funny that “Match surface” only requires 4 control points along the blend edge to achieve G2 continuity (using the same input surfaces split by isocurve), while “Blend surface” requires 6.
In the past I had some situations where “Blend surface” added hundreds of control points, whereas applying “Rebuild surface UV” to it, followed by “Match surface”, resulted in a very clean yet perfectly matching surface within the document tolerance. I guess that “Blend surface” plays it safe and uses it’s own tolerance method to make everything super tight between surfaces?

[pascal (Pascal Golay)]

Hello - BlendSrf uses Sweep2 - this generally makes surfaces with multiple knots, resulting in heavier surfaces.

-Pascal

[Rhino_Bulgaria (Bobi)]

It’s interesting to learn that “Blend surface” and “Sweep 2 rails” have something in common. No wonder that most of the time I use “RemoveMultiKnot” after building a surface with “Blend surface” and “Sweep 2 rails”, because it does a lot of clean up. However, in rare occasions “RemoveMultiKnot” may lead to worse surface flow, hence worse reflections. This is where “Rebuild surface UV” is the better option to reduce the control point count while maintaining equal distribution for the cp rows across the whole surface.

[norbert_geelen]

Just wanted to express my support for all the above mentioned points and suggestions by @Rhino_Bulgaria especially regarding edge alignment of hblend surface handles.
Norbert

[davide76]

“Blend surface” is one of the most important and used commands in Rhino; after six versions, and many years of development, this command should work best, and offer many adjustment options, more “refined”. Looking at VSR shape modeling would not hurt, in fact, developers should be inspired and take it as a model.
(moreover, the surface generated with blend srf should, automatically, propose a “remove_multi_knot”, avoiding useless waste of time; the surfaces should have, in automatic, few control points, and not many and useless, overflowing).
These are the improvements that a user would expect from a new version of Rhino, not just SubD and Grasshopper!
Surface generation and editing should always be the priority for Rhino, in every possible tool.

[eobet]

@pascal

FWIW, I generally loft and match in preference to BlendSrf-ing

But aren’t you glossing over the fact that you need to trim (at least in the above example) in order to loft and match, and thus end up with the complexity problem again? Isn’t VariableBlendSrf actually the preferred way, because that always pulls a rebuilt edge onto both surfaces and only trims afterwards, thus ignoring the issues with complex edges (only currently, the VariableBlendSrf implementation in Rhino 6 seems to build even more complex surfaces than the regular BlendSrf that this thread is focused on)?

[Rhino_Bulgaria (Bobi)]

In my above example I drew curves directly on the target surface with “Interpolate curve on surface”. Then I built a lofted surface between both curves. This way, I avoided splitting the surfaces there (check my 3d model where the surfaces remain uncut). Then, I used probably the most overlooked option of “Match surface” called “CurveNearSurface = On”. It exists only in the command line, so if people don’t pay close attention to see it on time (after picking the surface edge to be matched), they end up missing the chance and using “Match surface” with the default settings that accept only surface edges (for G0, G1 or G2) and curves (for G0) as an input.
Only “CurveNearSurface = On” allows the user to match the surface to the inside area of a target surface, either with or without a target curve near the latter.

[pascal (Pascal Golay)]

@eobet

But aren’t you glossing over the fact that you need to trim (at least in the above example) in order to loft and match, and thus end up with the complexity problem again?

No.

Lofting does not need a trim, MatchSrf does not need a trim - it can match anyplace on the surface.

-Pascal