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
Whatever is causing this operation to fail is subtle enough that what I have for you here is not enough decimal places to replicate it, I'm sorry I cannot provide a better test case right away. I will say that upgrading from f32 to f64 in my code did not fix the issue.
I am doing a lot of difference operations, so the red multipolygon was not generated by hand, but is the result of several differences. I seem to be able to do almost identical operations tens of thousands of times with different multipolygons before this issue is encountered. You can imagine there would have been other polygons, sharing edges to the left and right of the blue polygon, which have already been used to take a difference, making it such that the right piece of the red multipolygon essentially shares its exact edges with the blue triangle. Perhaps some subtlety exists where no floating point error whatsoever occurred in my special case and the two edges being exactly co-linear causes the algorithm to fail.
The text was updated successfully, but these errors were encountered:
I am getting the error "assembly segments must be eulierian" when taking the difference of two multipolygons.
I have graphed my two multipolygons in Desmos:
I am taking the difference between the red and the blue multipolygons, such that I expect the result to be the small red triangle.
Here's the two multipolygons as rust objects:
Whatever is causing this operation to fail is subtle enough that what I have for you here is not enough decimal places to replicate it, I'm sorry I cannot provide a better test case right away. I will say that upgrading from f32 to f64 in my code did not fix the issue.
I am doing a lot of difference operations, so the red multipolygon was not generated by hand, but is the result of several differences. I seem to be able to do almost identical operations tens of thousands of times with different multipolygons before this issue is encountered. You can imagine there would have been other polygons, sharing edges to the left and right of the blue polygon, which have already been used to take a difference, making it such that the right piece of the red multipolygon essentially shares its exact edges with the blue triangle. Perhaps some subtlety exists where no floating point error whatsoever occurred in my special case and the two edges being exactly co-linear causes the algorithm to fail.
The text was updated successfully, but these errors were encountered: