ObjectTable.AddSurface() can add multiple surfaces

AddSurface.3dm (18.1 KB) contains an invalid 1-face brep.

_Untrim will convert it into a valid 1-face brep of the underlying surface.

If the same is attempted via RhinoCommon, such as by using the code below, a 3-face brep is created.

Should a polysurface ever be created by scriptcontext.doc.Objects.AddSurface()?

import rhinoscriptsyntax as rs
import scriptcontext as sc

def main():
    idBrep = rs.GetObject("Select surface", rs.filter.surface, preselect=True)
    if idBrep is None: return
    rgFace = rs.coercesurface(idBrep)
    print rgFace.IsValid
    rgSrf = rgFace.UnderlyingSurface()
    print rgSrf.IsValid

if __name__ == '__main__': main()

Thank you,

Hi Steve,

Here is the log on the bad object:

brep.m_L[0] loop is not valid.
	end of brep.m_T[loop.m_ti[5]=5]=(16.3982,0.000628564) and start 
	of brep.m_T[loop.m_ti[6]=6]=(16.3982,0.000269198) do not match.
brep.m_F[0] face is not valid.
	brep.m_L[face.m_li[0]=0] is not valid.
ON_Brep.m_F[0] is invalid.

How was this bad object created?

Also, in your script, rs.GetObject will return the id of a Brep object. So you want your script do look something like this:

import rhinoscriptsyntax as rs
import scriptcontext as sc

def main():
    uuid = rs.GetObject("Select surface", rs.filter.surface, preselect=True)
    if uuid is None: return
    brep = rs.coercebrep(uuid)
    srf = brep.Faces[0].UnderlyingSurface()

if __name__ == '__main__': main()

The face is from a polysurface from a STEP file.

I am creating a script that repairs/reconditions breps. I want all of the work to be done to the Geometry.Brep before replacing the original DocObjects.BrepObject. Unfortunately, here is an example where the geometry of the revised DocObjects.BrepObject does not match the Geometry.Brep used to create it.

The trim error that the log is reporting is not directly related to why multiple surfaces are added. This can be demonstrated by:

  1. _Untrim(ming) the brep. The untrimmed brep is valid.
  2. Run the script on the untrimmed . Again, a polysurface is created.

It seems that SplitKinkyFaces() is automatically called before the brep is added to the document. Is this what is happening?

Why? Is Rhino not reading in your STEP file properly? If so, can we look at the STEP file?

The surface has numerous stacked control points. Run the PointsOn command and pick a corner point.

– Dale

I have been sending problem STEP files to @Chuck.

I was working on a brep modification script, but in order for it to be more successful, had switched my focus to brep repair/reconditioning, e.g., removing thin faces. Today, I was working on scripting the repair of invalid faces and discovered this behavior of AddSurface().

Some points are close to one another, not stacked. There are 2 kinks in the surface though.

If you add the surface as a BRep, you can use an overload of doc.Objects.AddBrep (...) in which you can specify not to split kinky surfaces.


This works. Thanks.

I just found this:


Of course, splits resulting in thin (relative to ModelAbsoluteTolerance) faces can also be problematic.