investigating possible OCC BuildCurve3d bug

[Chris_G]

Hi,
I was working on a Part.Spiral bug : spiral goes weird when the number of turns is too high.
It is similar to what happened to Part.Helix.

FC bug #954
OCC bug #23314

For the default Spiral, the bug appears at 43.4 turns.

This is caused by calling BRepLib::BuildCurves3d

Here are the default arguments :
BRepLib::BuildCurves3d(shape, Tolerance=1e-5, Continuity=GeomAbs_Shape::GeomAbs_C1, MaxDegree=14, MaxSegments=0);

MaxSegments=0 means the the tool self-computes the max number of segments : EvaluateMaxSegment

If I force MaxSegments=1,2,3,... the spiral goes wrong pretty fast, after a couple of turns only.
For MaxSegments=30, I get the failing limit to 43.4 turns (same as automatic mode MaxSegments=0)

Setting a much bigger number (MaxSegments=9999) allows to build big valid spirals (more than 500 turns).

So it seems the bug is in EvaluateMaxSegment that only raises the number of segments for BSpline curves ans surfaces, while it should probably also consider periodic surfaces.

This where I am stuck for now.
Maybe someone will want to join the bug hunt ...

BTW : I think this is probably related to this other bug :

Code: Select all

import FreeCAD
import Part
from math import pi
vec2 = FreeCAD.Base.Vector2d

cylFace = Part.makeCylinder(10,10).Face1
cyl = cylFace.Surface
line = Part.Geom2d.Line2dSegment(vec2(),vec2(100*pi,100))
edge1 = line.toShape(cyl)
Part.show(edge1)

[tanderson69]

MaxSegments=0 means the the tool self-computes the max number of segments : EvaluateMaxSegment

As a programmer, I am much too ignorant in the math to know where the magic number 30 comes from. As a seasoned modeler, I will say that large complicated splines cause large complicated modeling problems with a noticeable performance hit. So maybe '30' is some practical limit from those who know?

... while it should probably also consider periodic surfaces.

As for periodic surfaces, I have had good results using a topological approach. For example on a helix, cylindrcal surface, I will create one 2d pcurve that x spans the period (2pi). Then I will 'BRepLib::BuildCurves3d' that one pcurve to get 1 revolution of the helix. Then I will just copy that 3d curve and change the location. Wire then together to build a path if needed. I can make a really long helix without much trouble. Of course that is restricted to a cylindrical surface. My approach outside the cylindrical domain is similar. Instead of making 1 2d pcurve I make as many as wanted revolutions. Each one of the segments are parallel in a chain and restricted to the u period of the surface. Then I will 'BRepLib::BuildCurves3d' each segment and wire them together if needed to make a path. See picture.

periodicNonCylindrical.png (218.05 KiB) Viewed 890 times

[Chris_G]

Thanks for your feedback.
So, you also use a multi-edge approach, like TopoShape.makeLongHelix.
I can understand that it may be a more solid method, limited by available memory, while a single, long-bspline method will probably hit some limit earlier.
However, this is quite frustrating to see this old OCC bug still needing a user-side workaround.
And more : the other arguments (Continuity, MaxDegree) don't seem to be respected !

[tanderson69]

Thanks for your feedback.
So, you also use a multi-edge approach, like TopoShape.makeLongHelix.
I can understand that it may be a more solid method, limited by available memory, while a single, long-bspline method will probably hit some limit earlier.
However, this is quite frustrating to see this old OCC bug still needing a user-side workaround.
And more : the other arguments (Continuity, MaxDegree) don't seem to be respected !

Individual segments for a cylindrical helix will be significant at some scale, because you can instance the shape. instanceCount * (sizeof(spline_def) - sizeof(top_location)). Outside of the cylindrical helix, I agree, you don't gain anything if at all out of using single revolution segments. In case you missed it. https://opencascade.blogspot.com/2015/0 ... rface.html

Probably the bug isn't considered priority because you can pass in a max segments to fix the problem. You will probably have to file different bugs on the continuity and maxdegree being ignored. Get used to be frustrated with occt.
https://docs.google.com/forms/d/e/1FAIp ... Q/viewform

[Chris_G]

In case you missed it. https://opencascade.blogspot.com/2015/0 ... rface.html

Thanks for this interesting reading (even though my C++ level doesn't qualify me for that kind of acrobatics )

Get used to be frustrated with occt.

Why am I not surprised to hear this from you ?
I'll have a go at the survey.
Thanks.

[tanderson69]

Thanks for this interesting reading (even though my C++ level doesn't qualify me for that kind of acrobatics )

I should have pointed it out but the main reason I posted that link was to show that he has 10000 for his max segments. So my previous statement of: "So maybe '30' is some practical limit from those who know?", is wrong!