You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Start point == start point of the first edge,
end point == end point of the last edge.
i.e. BluemiraWire.start_point() == BluemiraWire.edges[0].start_point() BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point
Actual behaviour
Start point == start point of the LAST edge,
end point == end point of the FIRST edge.
i.e. BluemiraWire.start_point() == BluemiraWire.edges[0].start_point() BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point
This is because BluemiraWire.shape.Edges is sorted in reverse order, for reasons unclear to me.
Proposed solution
In _freecadapi::start_point and _freecadapi::end_point, Wrap the obj.Edges inside the Part.sortEdges function (and then unpack by indexing to [0]), before indexing to [0] and [-1] as before, respectively.
Note
I guess this means freecad's API uses memory in a weird/unpythonic way where lists are not ordered by default?
The text was updated successfully, but these errors were encountered:
OceanNuclear
changed the title
start and end points of bluemirawire ordering are messed up
start and end points of bluemirawire aren't reliable
Feb 22, 2024
je-cook
changed the title
start and end points of bluemirawire aren't reliable
Part Wire needs a specific ordering to reconstruct wire using deserialise_shape
Mar 6, 2024
After looking into this it seems like all the edges are reconstructed correctly by the deserialiser but when combined the shape created is not as expected. This could be down to a number of things but my guess is that it may be effected by #1347 and will be very hard to isolate until that is closed.
For now there is nothing particular that can be done to improve the situation other than to note that serialise_shape and deserialise_shape should be used with caution. The serialiser seems to produce what its expected however
Expected behaviour
Start point == start point of the first edge,
end point == end point of the last edge.
i.e.
BluemiraWire.start_point() == BluemiraWire.edges[0].start_point()
BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point
Actual behaviour
Start point == start point of the LAST edge,
end point == end point of the FIRST edge.
i.e.
BluemiraWire.start_point() == BluemiraWire.edges[0].start_point()
BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point
Example/Steps to reproduce
Loading the divertor face wire to examine.
Screenshots / Tracebacks
Explanation
This is because
BluemiraWire.shape.Edges
is sorted in reverse order, for reasons unclear to me.Proposed solution
In _freecadapi::start_point and _freecadapi::end_point, Wrap the
obj.Edges
inside thePart.sortEdges
function (and then unpack by indexing to [0]), before indexing to [0] and [-1] as before, respectively.Note
I guess this means freecad's API uses memory in a weird/unpythonic way where lists are not ordered by default?
The text was updated successfully, but these errors were encountered: