BRepBuilderAPI_FastSewing

I am just porting my code to 6.9.0 and trying to use the new BRepBuilderAPI_FastSewing algorithm.

Is there any advice can be offered on usage please.

I have the following code which is being passed a shell built of faces that have worked well with the older sewing algorithm.

BRepBuilderAPI_FastSewing seamstress(_sewingTolerance);
Standard_Boolean addedOK = seamstress.Add(shell);
seamstress.Perform();
unsigned int status = seamstress.GetStatuses();
TopoDS_Shape result = seamstress.GetResult();

The Add method always finds that all faces have infinite natural restriction and therefore the set that is used by perform is empty. I am creating the faces in the shell using

BRepBuilderAPI_MakeFace faceMaker(plane, wire, Standard_False);

There is a surface but all U V values are infinite

How do I create a face that this algorithm will accept?

Forum supervisor's picture

Dear Steve,

This algorithm has very narrow area of usage. It accepts only surfaces that have finite bounds. They are b-spline or bezier. Planes are not supported, but you can create a planar b-spline surface corresponding to your plane. At this, any pair of neighboring surfaces must match their parametrization along the common border. However, we do not consider this a good idea. On planes, the conventional sewing should work well and fast enough.
The goal of this new sewing algorithm is to make quick sewing of b-spline patches that were got by approximation of a cloud of points representing some complex curved surfaces. See also short algorithm description at the BRepBuilderAPI_FastSewing.hxx file.
Best regards
FSR

Steve Lockley's picture

Many thanks for the swift reply. I will try not to be too greedy for speed :-) The new boolean ops are looking good though, it has made improvements to my overall performance.
One thing I noticed is that the 6.9 release is more sensitive to the orientation of wires on a face, if holes are not the reverse of the outer then prisms are built incorrectly with the holes being positive space sometimes. this of course was bad geometry on my part and obeying the topology rules has fixed the problem. I comment just in case others find the same problem in their models.