Grasshopper Edge Surface produces Brep with 7 surfaces but only 4 faces


I use the Edge Surface component for generating a surface from three arcs. The result is unfortunately a Brep which has 7 surfaces but only 4 faces. This does not happen if I bake the arcs and generate the surface directly in Rhino.
Surfaces with surface index 3-6 correspond to the brep faces. Surface 0 is the whole surface with C0-continuities. Surface 1&2 are parts of it (see image). So there are kind of 3 valid results but only one is used for the brep. (14.7 KB)

Is there a fast way to recognize such results without checking for every surface if its index is related to a face?

In addition, Brep.CreateEdgeSurface(crvs); in a C# script produces one untrimmed surface…

Shouldn’t that be the expected result anyways?

Yes, but the problem is that the outcome is a brep which basically contains 3 versions of a valid solution (at least when using the component).
I access the Brep.Surfaces in my program, so I get “duplicated” entities.

See attached: (118.3 KB)

Note: no Crv checks (orientation [use DotProduct], ccx , self ccx, open/closed, valid , etc) are included - you should always do these in any C#

Shouldn’t that be the expected result anyways?

Not necessarily. You should always run SplitKinkyFaces after to cover cases using kinked edges, otherwise you will have creases which don’t usually play nice elseware. Rhino also does this (baking into rhino will also run split kinky as well). Unless you explicitly turn off crease splitting in Rhino which isn’t really advised.

Indeed: after Lewis did the usual thing (French GP) I added that option as well (118.5 KB)

Thank you!

Probably, I just have to check if the Brep.Faces.Count == Brep.Surfaces.Count to avoid such bugs in the general case. If not, I can just access the Surfaces by using Face[i].UnderlyingSurface() in order to avoid having three times the “same” geometry in my model/code. The face list is hopefully unique.

So the Grasshopper component automatically calls SplitKinkyFaces() with the Rhino tolerance. And that leaves unused Surfaces in the brep, which is a Bug(?).

When you call brep.Compact() or brep.CullUnused* that should also clean up the brep, no? (17.2 KB)

Er… Brep class has no such Method/Property I’m afraid.

That said obviously the Brep.Faces yields a unique collection of BrepFaces (and each one refers - obvioulsy - to a unique Underlying Surface).

That said BrepFace.IsSurface Property is true if the face is synonymous with the underlying surface

It does? I use it in the C#component in the file which I originally posted. I am sorry but I don’t understand.

The problem is that my whole code refers to brep.surfaces list in a brep geometry but apparently it is possible to generate breps which do not have consistent lists. So either I check for consistence or I access the surface with Face.UnderlyingSurface in the whole code. I am also wondering if the face list is then always unique or if similar problems can also happen there.

Apparently that Property added in R6 SDK (but I’m in the R5 bandwagon).

In any case post here a complete case (with examples) and list what type of checks you want to do.

Update: appears that R5 supports that Property as well (MIA in SDK): (15.4 KB)

Why not remove the unused Surfaces in the surface list then? In your example three of the surfaces are unused, so no face refers to them, once you clean up the brep, those also get removed and everything is consistent? Maybe a question for @dale or @DavidRutten, but I doubt that one face can actually refer to more than one surface?

@dsonntag - after a number of operations on a Brep, sometimes is necessary/desired to clean up the object using Brep.Compact.

– Dale

Hello from 2022 (:, I have studied the subject in detail, but I want to solve this problem without using C+, that is, only with GH formulation. Do you think this is possible?