Brep.CreateBlendSurface Method bugs and feature request

Rhino Developer
1

I wanted a non-interactive in-code C# equivalent for the BlendSrf command. I tried scripting the
_-BlendSrf command but it fails out of scripting without registering the second input point. [Is there a way in script to cycle forward thru the selection prompts that I don’t know about (“Enter” skips too far ahead and effectively ends the command)?]

So, I tried the new Brep.CreateBlendSurface Method in Rhino 6.

First, the Brep.CreateBlendSurface Method does not appear to have an equivalent to the “Same Height” checkbox that is available in the interactive BlendSrf command. That “Same Height” checkbox yields exactly the results I want. Am I missing something about the Brep.CreateBlendSurface Method?

Second, the Brep.CreateBlendSurface Method does a poor job of matching the input surface edges requiring manual adjustment with the MatchSrf command. That pretty much cancels the usefulness of the Brep.CreateBlendSurface Method right there if I have to go in and manually fix the output. Is there a C# equivalent for the MatchSrf command that I might use to “finish” the surface in two steps instead of one (also rectifying the other problems noted below)?

Third, the Brep.CreateBlendSurface Method does not respect the direction of the isocurves of the input surface but only creates its own isocurves perpendicular to the input surface edge, same as the curves created by the Brep.CreateBlendShape Method. This results in a surface quite different than the desired surface created by BlendSrf.

I tried using the Brep.CreateBlendShape Method to create curves to use as input to a Sweep 2 command, but aside from the perpendicularity problem noted above, the resulting sweep has unacceptable curvature waviness in comparison to the BlendSrf surface. Likewise using curves created by CreateInterpolatedCurve Method followed by Sweep 2 gives unacceptable surface waviness.

Could the code for BlendSrf be made available so I could modify it to meet my needs (non-interactive) and incorporate it in my plug-in?

[C++] RhinoSdkBlend::SurfaceBlend gives inaccurate results
2

Hi @davidjgall,

Are you using Rhino 5 or 6? Can you post your geometry so I can see the results you are achieving?

Thanks,

– Dale

3

Hi Dale,

I’ll have to get back to you on this next weekend.

Thanks,

David

4

Dale,

Some things I encountered with Brep.CreateBlendSurface. (I’m working in Rhino 6.) First, the Blend didn’t match the input surface. The green blend shown here was intended to match the indigo surface, but missed it by 0.007mm at the leading edge. Funny, though, setting the drawing tolerances closer had no effect, but scaling everything up by a factor of 100 in code to use the Brep.CreateBlendSurface method, then scaling everything down to insert it into the document did fix this error. Notice also the waviness along the edge where it does, at first glance, seem to match.

1
11360×797 362 KB

For comparison, here’s the result of the interactive “Blend Surface” command overlaid in light green. I used the defaults on the Blend Surface command except I selected the “Same Height” checkbox.

2
21360×797 493 KB

Here’s the other end of the Brep.CreateBlendSurface shown initially. Note that the surface edges are in no way aligned with the surface edges of the input surface.

3
31306×765 150 KB

Again, overlaying the results of the interactive Blend Surface command which yields the results I had expected of the Brep.CreateBlendSurface method.

4
41306×765 208 KB

At this point I must mention my disappointment that the “Same Height” modifier is not available programmatically in the Brep.CreateBlendSurface method, giving the two surfaces such great difference in this region of my model. However, the surface edges resulting from the Blend Surface command have clearly retained the direction of the surface edges of the input surface whereas the Brep.CreateBlendSurface method has not.

Viewing the same area from a different angle shows that the Brep.CreateBlendSurface has gone off on its own a bit with regard to the surface edges. They seem to veer too far to the left in the image below before bending back to join the lower surface.

5
51306×765 95.2 KB

Contrast that again with the Blend Surface command which takes a less circuitous path:

6
61306×765 119 KB

Selecting each surface in turn to highlight the isocurves reveals that it is not just the edge curves that are skewed on the Brep.CreateBlendSurface surface. The “shoulders” or “bulge” of the part is distinctly larger for the Brep.CreateBlendSurface surface than for the Blend Surface surface.

7
71306×765 116 KB

Looking closely, you’ll also notice that the isocurves for the Brep.CreateBlendSurface surface are everywhere skewed and not aligned in the direction of the input surface isocurves. While maintaining tangency with the input surface in the plane perpendicular to that surface at the isocurve endpoints, the direction of the isocurves is not tangent to the input isocurves in-plane, whereas the Blend Surface surface isocurves are much more well-behaved.

8
81306×765 130 KB

In order to try to understand the nature of the problem with the Brep.CreateBlendSurface method, I generated a series of Brep.CreateBlendShape curves which promised to have similar characteristics to what I was seeing with Brep.CreateBlendSurface. Interestingly, the only Brep.CreateBlendShape curve that matched the Brep.CreateBlendSurface surface was the edge curve of the Brep.CreateBlendSurface surface. Except for those two curve, all of the Brep.CreateBlendSurface surface’s isocurves deviated significantly from the Brep.CreateBlendShape curves. I’ve illustrated that with the two images below in which I extracted more than the default number of isocurves from the Brep.CreateBlendSurface surface (shown in black) to contrast with the Brep.CreateBlendShape curves shown in orange.

First, with the original green surface to show that the Brep.CreateBlendShape curves are, indeed, a fairly good approximation of what the Brep.CreateBlendSurface produces:

9
91306×765 183 KB

And again without the surface in order to more clearly show the substantial deviation of the isocurves.

10
101360×797 65.3 KB

I have much more to say on this topic but, sadly, I have spent far too much time on it already. I hope I’ve given you something to work on. I don’t know what the intent was of including the Brep.CreateBlendSurface method but I took it to be a programmatic version of the Blend Surface interactive command. If that was the case, it has not produced acceptable results; if it is, indeed, producing the intended result then I cannot fathom the intent, the implementation, or the topology.

Thanks for taking the time to look at this.

  • David
6

Hi @davidjgall,

Thanks for all the details. It turns out that the only thing in common with the BlendSrf command and the Brep.CreateBlendSurface method is the word blend, as this method is not used by the command. Thus, there isn’t much we can do, other than to tell you to use the command.

I’ve logged an issue to add a better blend function to the Rhino SDK and RhinoCommon.

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

Thanks,

– Dale

7

HI Dale,

Thanks for logging that issue. It’s kind of disappointing that the concept of blending two surfaces is so ill-defined that the two functions can yield such disparate results yet both qualify as “blends.” Perhaps the Brep.CreateBlendSurface command should be renamed (or at least documented) as a “connect surfaces” command instead of a “true blend” as produced by BlendSrf.

That said, is there any hope of implementing a programmatic interface to the interactive BlendSrf command or open-sourcing the code so hackers like me can automate it? It yields a most pleasing result and can’t be duplicated by any other approach that I’ve found.

Also, there is a bug in BlendSrf that might merit investigation: the “Same Height” option check-box state is persistent between command invocations but the initial command result is buggered if “Same Height” is in the “checked” state when the command is invoked, requiring one to un-check then re-check the option box to get a proper application of the “Same Height” behavior.

That’s all for now,

– David

8

Hi!

I’ve just taking a look to the CreateBlendSurface method and I’ve got the same problem as @davidjgall, any news about when this is going to be done @dale? Would be good to have it for Rhino7 if possible :slight_smile:

Regards,

9

Sorry, no. I doubt it will make it into Rhino 7 - at least the initial release.

– Dale

10

In that case, please update your bulletin board software to include a “frowny face” icon selection next to the “heart” icon and the “Reply” button… :frowning: