Open adamgit opened 6 months ago
adamgit
commented
6 months ago Correction: it's all edges, I misunderstood the .ClockwiseCell - it doesn't supply the edges in clockwise winding, it supplies them in the order as if they were clockwise, but their directions are still random. Need a second pass to fix their directions to give an actual winding.
RudyTheDev
commented
6 months ago Ah, I see. I was wondering what sort of edge case I was missing because I check ClockwiseCell in unit tests extensively.
But yes, ClockwiseCell returns the edges in an order where one follows the other logically, but does not guarantee any order for each edge's start/end points. I guess the simplest explanation is to think what direction is the middle line supposed to go to be considered clockwise for both cases:
You can see that "clockwise" actually depends on the edge's position relative to the cell. And I can't really change start/end points once they are assigned.
You are probably wanting to use ClockwisePoints if you are trying to wind around the cell.
May be there is a nicer way I could be returning this, although I am not really sure. I guess I haven't implemented getting edges from a point yet, so following along points doesn't let you "look back" at the edges.
adamgit
commented
6 months ago Yep, if you're working with 3D meshes I don't see a way around this - every triangle must by definition have the same winding order, all processing/algs will break otherwise - so it's normal to make sure the triangles are all 'correct' at the start of processing.
Points 'works' but discards meta information, meaning we lose a lot of the value of Voronoi in the first place (and would have to manually reconstruct it, e.g. by calculating neighbours).
My current workaround is a 10 lines piece of code that iterates through the edge list after I've extracted them from the lib, flipping edges that are incorrect, until they are all in the same CW direction. Works fine.
On Sun, 5 May 2024 at 20:36, Rudy @.***> wrote:
Ah, I see. I was wondering what sort of edge case I was missing because I check ClockwiseCell in unit tests extensively.
But yes, ClockwiseCell returns the edges in an order where one follows the other logically, but does not guarantee any order for each edge's start/end points. I guess the simplest explanation is to think what direction is the middle line supposed to go to be considered clockwise for both cases:
clockwise.png (view on web) https://github.com/RudyTheDev/SharpVoronoiLib/assets/3857299/99cc1971-34b5-4cf5-b033-e6a84014b4f7
You can see that "clockwise" actually depends on the edge's position relative to the cell. And I can't really change start/end points once they are assigned.
You are probably wanting to use ClockwisePoints if you are trying to wind around the cell.
May be there is a nicer way I could be returning this, although I am not really sure. I guess I haven't implemented getting edges from a point yet, so following along points doesn't let you "look back" at the edges.
— Reply to this email directly, view it on GitHub https://github.com/RudyTheDev/SharpVoronoiLib/issues/6#issuecomment-2094923858, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACHL6OLWCEBZOOKXKVPVF3ZA2C2HAVCNFSM6AAAAABHH6CNGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHEZDGOBVHA . You are receiving this because you authored the thread.Message ID: @.***>
Approx 50/50 chance of this happening, that when requesting .ClockwiseCell, the Edge instances I get are all correct except the final one, where Start and End are reversed.
Guess: the code for ClockwiseCell has an out-by-1 error and is failing to reverse the final edge, so its a matter of luck whether the edge was already clockwise before the conversion took place.