This is probably more about OpenCascade itself than about this wrapper, but anyway...
I'm shocked at how hard it is to get TopoDS_Edge to ALWAYS give me the start and end points such that the edges form a counter-clockwise cycle around the face.
For a boundary representation, this seems really fundamental to me. The outside edges of a face form a loop in one direction (counter-clockwise) and a loop for a hole in the face has edges that go in the opposite direction.
So every edge has a direction. And (except for degenerate cases) every edge is shared with another face which sees the same edge but in the opposite direction.
The current implementation of start_point(), for example, gets the point from the underlying Curve:
let curve = ffi::BRepAdaptor_Curve_ctor(&self.inner);
let start_param = curve.FirstParameter();
let point = ffi::BRepAdaptor_Curve_value(&curve, start_param);
But I found that this didn't reliably give me the points in the "correct" order. So I changed to this:
let vert = ffi::ShapeAnalysis_Edge_FirstVertex(&self.inner);
let point = ffi::BRep_Tool_Pnt(&vert);
And I thought had the problem solved, but now I'm finding cases where the ordering of the two vertices for an edge changes after a simple translation or rotation of the shape to a new position.
I've started investigating the orientation property of TopoDS_Shape, but whatever it means, it seems unrelated to my expectation for the ordering of these edge loops. For example, right after a construct a 3D box solid, one of the faces looks like this:
Edge from [300, 0, 30] to [300, 0, 0] -- TopAbs_REVERSED
Edge from [300, 50, 30] to [300, 0, 30] -- TopAbs_REVERSED
Edge from [300, 50, 0] to [300, 50, 30] -- TopAbs_FORWARD
Edge from [300, 0, 0] to [300, 50, 0] -- TopAbs_FORWARD
These edges do form a loop, in the sense that each vertex appears as the start point exactly once and as the end point exactly once, so my expectation would therefore be that all the edges would have the same orientation, but two of them are reversed.
I have to assume at this point that my expectations aren't correct for OpenCascade's design.
This is probably more about OpenCascade itself than about this wrapper, but anyway...
I'm shocked at how hard it is to get TopoDS_Edge to ALWAYS give me the start and end points such that the edges form a counter-clockwise cycle around the face.
For a boundary representation, this seems really fundamental to me. The outside edges of a face form a loop in one direction (counter-clockwise) and a loop for a hole in the face has edges that go in the opposite direction.
So every edge has a direction. And (except for degenerate cases) every edge is shared with another face which sees the same edge but in the opposite direction.
The current implementation of start_point(), for example, gets the point from the underlying Curve:
But I found that this didn't reliably give me the points in the "correct" order. So I changed to this:
And I thought had the problem solved, but now I'm finding cases where the ordering of the two vertices for an edge changes after a simple translation or rotation of the shape to a new position.
I've started investigating the orientation property of TopoDS_Shape, but whatever it means, it seems unrelated to my expectation for the ordering of these edge loops. For example, right after a construct a 3D box solid, one of the faces looks like this:
These edges do form a loop, in the sense that each vertex appears as the start point exactly once and as the end point exactly once, so my expectation would therefore be that all the edges would have the same orientation, but two of them are reversed.
I have to assume at this point that my expectations aren't correct for OpenCascade's design.