Subclassing Geom_Curve

Forums: 

I'm experimenting with custom curves by subclassing Geom_Curve. I've put together a simple implementation, Geom_SineCurve, which I believe satisfies the Geom_Curve API (I've attached the header/cpp file. The cpp file is minimal as I am just testing this out at the moment).

I notice some odd behavior presumably occurring when the curve is triangulated (or the edge equivalent). In some cases the result appears to be correct, however for certain values of the trimmed curve parameter range (p0 = 0, p1 = 3), it seems like the edge is being triangulated to a straight line. This then causes issues when making a prism (see attached picture). I suspected it might be an issue with visualization but upon making a prism and exporting the mesh to an STL, the result is a flat rectangle.

To generate the edge I am using the following

    Handle(Geom_SineCurve) sc = new Geom_SineCurve(1, 0.5, 0.5);
    Handle(Geom_TrimmedCurve) tc = new Geom_TrimmedCurve(sc, 0, 3); // does not appear to make a difference with "sense" set to true or false

    TopoDS_Edge edge = BRepBuilderAPI_MakeEdge(tc);

    BRepLib::BuildCurves3d(edge); // not sure if this is necessary

With a sine wavelength = 1, amp = 0.5, phase offset = 0, it seems like the issue occurs whenever abs(pStart%wavelength - pEnd%wavelength) < 0.052238850585170 +- 1E-15. (i.e. the values are close to an integer number of wavelengths apart) The sin of this value comes to 0.05221509474, cosine comes to 0.9986358615. Perhaps there is a precision problem causing these "magic values"?

I dug around a bit in the BRepLib_MakeEdge source (used by BRepBuilderAPI_MakeEdge), but didn't find anything that would give a hint as to why this happens. If anyone has a suggestion where to look next I would appreciate it!!! :)

Luke Dobinson's picture

I should add, I have tested this with OCC 7.6.3

gkv311 n's picture

Geom_Curve has a fixed hierarchy of classes in OCCT and doesn't support creation of subclasses at application level (save the very trivial cases). It will require modifying OCCT itself to support new curve types within all algorithms.

Luke Dobinson's picture

Thanks for the answer! Ah so directly implementing custom curves is not supported then. I was afraid of that. Is there a preferred method of approximation that should be used? It would be great if there was some general way to approximate an arbitrary function using the conics/bezier curves that are supported. Continuity is not a major issue for my purposes, i.e. all the curves I want to approximate are CN differentiable. If not then I can implement my own approximation, but I thought I would ask.