Understanding Brep operations Rhino vs RhinoCommon


during the day, it happens quite often that methods like


do not produce the correct result while adding the brep to the document and using the respective commands inside Rhino brings the desired effect.
Sometimes increasing the tolerance does help, but it is unreliable as often even a tolerance of 0.1 or even 1 does not do the same as when using the command inside a rhino doc with a 0.01 tolerance.

How can I go about increasing the reliability of the methods and mirror the exact same effectivnes as using the rhino commands?

All geometry is valid.


if I’m not mistaken usually a failure mostly happens if you create conditions which are difficult to solve.
So for instance you like to union two breps which exactly neighbouring eachother. Then, because of the floating point tolerances, this is a unclear situation and the better algoritm may have more options to deal with them.

Another problem might be due to the cleaness of you geometry. If you keep span and controlpoint count low, then you will mostly create valid unions, merges etc.

Yet another common issue is if you process non-Nurbs surfaces (f.e. extrusions), which first need to be converted to NurbsSurfaces until they can get processed further correctly. Don’t know why Rhinocommon has problems with that, but its often solving some issues.

I think the main issue however is that a command differs from the Rhinocommon method and usually the Api call is the weaker algorithm. I think there is nothing you can do about it, other then working clean and and distinct. As a last resort, do what the shortcuts like Boolean and Capping do for you anyway. Create and join surface by surface.

1 Like

In most cases, RhinoCommon is calling the same APIs as an equivalent Rhino command. However, the commands often do “a little more” to take special cases into account.

@rgr - please provide some code we can use to reproduce the problem. Include any additional files/geometry if needed.


– Dale

1 Like

Interesting, I didn`t notice this behaviour with extrusion yet, however, I usually use brep objects if possible, as it almost always provides the functionality I need.

Yes I believe that too, that the command does something “more”, but it makes for a less intuitive way to “model” something by code if you can not use the same approach as you would doing it by hand, that is why I want to get as close as possible. If there is no other way, writing our own Boolean Routines would be an option, but we prefer to avoid a) double work and b) having multiple ways to do something in one framework/for one application.

Dale, can you share some insight on what checks the command uses?

I replicated the general workflow inside this command, the code is almost as in the current case. If you try it out, you should get an open brep after running the command, which you can cap using the command.
Please note that there is the “example.3dm” which has to be on the desktop OR you have to change

string filepath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop), "example.3dm");

in line 38.

BrepCapFail.cs (4.9 KB)
example.3dm (64.6 KB)

Hi @rgr,

Rather than doing this:

if (brep.SolidOrientation == BrepSolidOrientation.Inward)

try doing this:

var capped_brep = brep.CapPlanarHoles(tolerance);
if (capped_brep.SolidOrientation == BrepSolidOrientation.Inward)

BrepCapFail.cs (3.3 KB)

– Dale

1 Like

Ha, that is a rather plain oversight, thank you.

However, the question still remains, if you could share some info about how best to work around brep operations not working and what kind of checks the commands add?
I`m not asking for code, just for ideas on what to look out for because these things do happen from time to time, and we often have workarounds like splitting the cutter with the brep and joining those faces together etc.

Hi @rgr,

I’m not sure how to answer this - sorry.

I can only suggest that when you run into issues, let us know.

– Dale