investigating possible OCC BuildCurve3d bug

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
Chris_G
Posts: 1583
Joined: Tue Dec 31, 2013 4:10 pm
Location: France
Contact:

investigating possible OCC BuildCurve3d bug

Postby Chris_G » Sat Aug 22, 2020 12:13 pm

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)

User avatar
tanderson69
Posts: 1545
Joined: Thu Feb 18, 2010 1:07 am

Re: investigating possible OCC BuildCurve3d bug

Postby tanderson69 » Sat Aug 22, 2020 2:04 pm

Chris_G wrote:
Sat Aug 22, 2020 12:13 pm
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?



Chris_G wrote:
Sat Aug 22, 2020 12:13 pm
... 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
periodicNonCylindrical.png (218.05 KiB) Viewed 521 times
User avatar
Chris_G
Posts: 1583
Joined: Tue Dec 31, 2013 4:10 pm
Location: France
Contact:

Re: investigating possible OCC BuildCurve3d bug

Postby Chris_G » Sat Aug 22, 2020 2:53 pm

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 !
User avatar
tanderson69
Posts: 1545
Joined: Thu Feb 18, 2010 1:07 am

Re: investigating possible OCC BuildCurve3d bug

Postby tanderson69 » Sat Aug 22, 2020 5:19 pm

Chris_G wrote:
Sat Aug 22, 2020 2:53 pm
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
User avatar
Chris_G
Posts: 1583
Joined: Tue Dec 31, 2013 4:10 pm
Location: France
Contact:

Re: investigating possible OCC BuildCurve3d bug

Postby Chris_G » Sat Aug 22, 2020 5:41 pm

tanderson69 wrote:
Sat Aug 22, 2020 5:19 pm
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 :lol: )
tanderson69 wrote:
Sat Aug 22, 2020 5:19 pm
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.
User avatar
tanderson69
Posts: 1545
Joined: Thu Feb 18, 2010 1:07 am

Re: investigating possible OCC BuildCurve3d bug

Postby tanderson69 » Sun Aug 23, 2020 1:40 pm

Chris_G wrote:
Sat Aug 22, 2020 5:41 pm
Thanks for this interesting reading (even though my C++ level doesn't qualify me for that kind of acrobatics :lol: )
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!